Hey Folks,
recently we have updated the Mozilla Plugincheck Page (so far en-US only, other locales ) with new Layout etc.
We are working on support of other Browsers (for those who are not using Firefox yet) so stay tuned. Also when you have ideas how to improve Plugincheck let me know.
Big thanks to Schalk Neethling for updating the Site!
- Tomcat
Nothing complicated, just paste the code below into your functions.php file, save it, and you're done.
// Break Out of Frames for WordPress
function break_out_of_frames() {
if (!is_preview()) {
echo "\n<script type=\"text/javascript\">";
echo "\n<!--";
echo "\nif (parent.frames.length > 0) { parent.location.href = location.href; }";
echo "\n-->";
echo "\n</script>\n\n";
}
}
add_action('wp_head', 'break_out_of_frames');
Thanks to WP Mix for this very handy tip!
This post summarizes the top “chrome hangs” reported to Telemetry by Nightly 22 on Windows during the first half of March.
A “chrome hang” is a period of time during which the main thread is stuck processing a single event. It is not a permanent hang. By default, Nightly on Windows reports any chrome hangs lasting at least 5 seconds to Telemetry. You can see your own chrome hangs from your current browsing session in your Nightly’s about:telemetry page.
There are roughly 270,000 Firefox sessions with chrome hangs in this data set, reporting a total of ~570,000 chrome hang stacks. There are 84,000 “unique” stack signatures, but the heuristic I use for stack signature generation is far from perfect.
The top hangs:
* I removed JS-only stacks that did not contain any useful identifying frames
The raw chrome hang data is challenging to categorize perfectly since there is a very long tail of stack signatures.
Instead, I used a simple heuristic to categorize the stacks, and I found that hang stacks involving plugins are by far the most common (36% of hangs), stacks with font operations are second (12%), GC and CC are third (10%), and the HTTP cache is fourth (4%). The long-tail of “other” operations makes up the remaining 38% of the data.
After filtering the data set to only the top 100 most common hang signatures, I found the distribution of hangs mostly unchanged. Most of the hangs are again caused by plugins: 53 out of the top 100 signatures are plugins (67% by number of hangs). Font-loading operations take second place (11% by number of hangs), followed by GC and CC (9%) and locking in the HTTP cache (4%). The remaining 9% of hangs is mostly made up of long-running JavaScript scripts. Unfortunately, the chrome hang reporting code currently does not walk the JavaScript stack, so it’s impossible to obtain useful information out of pure JavaScript hangs.
Data: Top 100 chrome hang stack signatures
We’ve known for a while that plugins are a major source of browser unresponsiveness. In particular, the initial synchronous load of the plugin’s library and the creation of a new plugin instance are the most common hang stacks. The top 100 list also shows plugins taking a long time to handle events and destroy plugin instances. There is also a large number of stacks where Flash hangs cause Firefox hangs on account of Windows input queue synchronization (bug 818059).
Since we’re stuck with the synchronous NPAPI, I suspect we won’t be able to minimize the impact of of plugin hangs until we separate content and chrome into separate processes (i.e. the Electrolysis project). In the short term, we’re mitigating some of the plugin pains by adding read-ahead to improve plugin library loading speed (bug 836488) and starting with Firefox 20, we’re showing users a UI that allows them to terminate an unresponsive plugin after 11 seconds (bug 805591). Both of these patches were written by Aaron Klotz.
Benoit Girard, Georg Fritzsche and Benjamin Smedberg are working on uncovering the causes of some of these hangs by adding profiling support to the plugin-container.exe process (bug 853358 and bug 734691) and exposing IPC message information to the profiler (bug 853864 and bug 853363). You can find Benoit’s write-up here.
Finally, it might also be possible to move some of the heavy plugin operations off the main thread (e.g. bug 856743).
After plugins, font loading operations are the most frequent single category of browser hangs. To see an example of a fonts hang, restart your computer (or clear your OS disk cache by other means) and load the Wikipedia homepage (bug 832546). You should see a hang lasting at least 100ms (depending on your storage device) while the browser loads dozens of fonts from disk to render all the different languages displayed on the page.
There are several existing bugs for font hangs (bug 734308 and bug 699331), but I’d like to ask someone with some knowledge of the fonts code to file individual bugs for the rest. I filed bug 859558 as a catch-all bug for all the font stacks that I did not recognize.
Data: Top 50 chrome hang stack signatures, excluding plugin hangs
After plugins and fonts, the locking done in the HTTP network cache causes most of the chrome hangs. It seems the main thread often gets blocked waiting on a lock that is being held by a background cache thread. I assume the background thread is doing disk I/O while holding the contended lock. If you move your Firefox profile to a slow a storage device (e.g. an SD card), you can reliably reproduce these hangs by visiting new sites. The Necko team is currently working on plans for a new network cache design.
Garbage Collection & Cycle Collection are the third most common category of hangs. Surprisingly, incremental GC stacks also show up in the top 50.
In addition to the hangs described above, there is a significant number of stacks with JIT-ed JavaScript code, page reflows and other content operations. Since chrome hangs don’t report the names of JavaScript functions on the stack and Telemetry doesn’t collect page URLs, these stacks are not useful. I filtered out these types of stacks and came up with a list of the top 50 “other” hangs.
Data: Top 50 chrome hang stack signatures, excluding common hang types (plugins, GC, CC, HTTP cache, font, content hangs)
This list shows:
I have not identified all of the hangs in this top list:
Plugins are the foremost cause of Firefox janks lasting multiple seconds. Fonts, GC/CC, and the HTTP network cache are also common sources. The long tail of hang signatures contains new bugs, some of which could be fixed quickly.
Just paste the following code snippet into your functions.php file:
add_action('template_redirect', 'redirect_single_post');
function redirect_single_post() {
if (is_search()) {
global $wp_query;
if ($wp_query->post_count == 1) {
wp_redirect( get_permalink( $wp_query->posts['0']->ID ) );
}
}
}
Thanks to Paulund.co.uk for the snippet!
As a followup to this post announcing the @supports at-rule implementation, Firefox Nightly now (as of bug 779917) has support for the DOM API part of the CSS Conditional Rules Level 3 specification. The new CSS.supports function can be called in two different ways. The first is with a property name and value pair:
if (CSS.supports("display", "flex")) {
// do something relying on flexbox
}
The second is with an entire expression that can appear just after @supports:
if (CSS.supports("(display: flex) and (display: grid)")) {
// do something relying on flexbox and grid layout
}
As with the @supports rule itself, the CSS.supports() API lives behind the layout.css.supports-rule.enabled pref, which is enabled by default in Nightly and Aurora builds of Firefox.
[Edited 28 December 2012 – fixed display: flexbox to display: flex as pointed out by fantasai]
By Wayne Thorsen (@waytho), VP of Global Partnerships at Telefónica Digital
Last week, I drove 16 hours (a shut down at Seattle International airport) to be part of the APPNATION IV conference as a panelist in ’Welcome to Thunderdome! Native apps vs HTML 5/ mobile web’.
The long drive was absolutely worth it.
The aptly titled session took the shape of an in-depth panel discussion chaired by Ina Fried of All Things D (see above), along with Todd Simpson (Chief Innovation Officer, Mozilla), Chris Martin (VP Engineering, Pandora) and Mark Young (VP, Mobile and Connected Devices, NBC Universal).
We debated the current state of the mobile app ecosystem, and in particular the HTML 5 vs Native App divide. So here are my five key takeaways from the discussion:
My final word? The best experiences are going to come from somewhere that’s truly open. And some recommended reading you must take a look at below…
Debunking five big HTML5 myths – Christian Heilmann, Principal Developer Evangelist at Mozilla for HTML5 and open web
The Making of Fastbook: An HTML5 Love Story - Jamie Avins and Jacky Nguyen, engineers at Sencha
Slideshare: Firefox OS will save the Web on mobile - Carlos Domingo, CEO of Telefonica I+D
Mozilla Hacks – the web developer blog
Is Microsoft working on a new web standard?
Every once in a while I come across domain name registrations that leave me puzzled.
Microsoft registered six domain names yesterday related to “Karaoke Web Standard”. I’ve searched the web and can’t find anything related to Microsoft and a new web standard by the karaoke name.
The only thing that comes up is karaoke software.
So that leaves a couple possibilities.
Either these domains are basically meaningless and relate to some old initiative or software that is buried in the search engines, or Microsoft is getting ready to launch a new initiative for a web standard.
Any one in the know care to comment?
Here are the domains they registered yesterday:
KaraokeWebStandard.com
KaraokeWebStandard.net
KaraokeWebStandard.org
KaroakeWebStandard.com
KaroakeWebStandard.net
KaroakeWebStandard.org
© DomainNameWire.com 2012. This is copyrighted content. Do not republish.
Latest domain news at DNW.com: Domain Name Wire.
No related posts.
Simply paste the code snippet below in your functions.php file:
add_filter('the_generator', 'digwp_complete_version_removal');
function digwp_complete_version_removal() {
return '';
}
Thanks to Jeff Starr for the tip!