While they chug along to Firefox 4, Mozilla just released Firefox 3.6.4 (and quickly followed up with 3.6.6) on the world, sporting a new feature – plugin isolation. By isolating plugins to a different process, Firefox catches up to Chrome in stability, by ensuring that a rogue plugin that crashes does not bring down the whole browser, instead you get the sad face informing you that something has happened. This is a great end-user feature which will increase the general reliability of a user’s browsing experience – but we aren’t just users, are we?

Firefox will shut down a plugin when it is deemed to be either dead, or frozen. Unfortunately frozen is the state that the plugin will enter when you try to debug it (say, through Visual Studio), causing Firefox to kill the plugin and continue on its merry way. There have a been a number of proposed solutions, mainly around disabling the plugin container for Silverlight (see this forum post). Unfortunately, while this works for debugging, this is not a real user situation that you are debugging (since you’re no longer locked in the container, which is the expected state for any user running your app). In order to get Firefox to still run Silverlight in the container, but not kill it when it detects a Freeze, do the following:

1. type about:config
2. find dom.ipc.plugins.timeoutSecs (you can start typing it in the filter)
3. change the value to -1

This effectively cancels the timeout so that even though the plugin is no longer responding to Firefox’s NSAPI messages, it will not be killed.

Happy bug hunting!

Internet Explorer 8 ships with a feature to increase reliability by spreading tabs across multiple processes, unfortunately if you want to profile (or debug) a plugin (Silverlight, Flash etc) then you need to know the correct process ID (PID) to profile, as the normal PID will usually be of the iexplore.exe container, as opposed to the tab that you want to target.

To make things easy, you can disable per-tab processes by modifying the following key\value:

HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\TabProcGrowth

This vale may not exist, so go ahead and create it as a DWORD with a value of 0. To restore normal IE8 operations (I personally run with it constantly disabled and haven’t seen much of an adverse affect, but on lower powered machines or if you’re not constantly profiling) just delete TabProcGrowth.

You can also automate this by adding it to a .reg file or by using the following command line commands (in a batch file etc):

Disable TabProcGrowth

reg add "HKCU\SOFTWARE\Microsoft\Internet Explorer\Main" /v TabProcGrowth /t REG_DWORD /d 0 /f

Back to default

reg delete "HKCU\Software\Microsoft\Internet Explorer\Main" /v TabProcGrowth /f

I’m constantly machine hopping at work, using remote desktop to administer or actually work on a remote machine. This usually means that every now and then I need to restart the machine, an option which is conspicuously missing from the Start menu – so here are a couple of options I usually use:

1. Run “shutdown -r -t 0″ (this basically requests a restart within time “0″, ie immediately). Luckily this doesn’t require elevation so runs smoothly. See “shutdown /?” for more options (including shutdown).

2. Click on the taskbar (away from a running app) and hit “Alt + F4″ and you’ll get a dialogue asking you what you want the machine to do – one of the options is restart!

Hit Alt+F4 on the taskbar of a remote session, and this is what you'll see

Rodney points out in the comments below that:

Alternatively, you could try “shutdown -i” for an easy to use GUI to shutdown, restart, etc a bunch of machines, remotely.

Thanks for the tip!

The IE9 preview has been out for a while (if you haven’t checked it out, then do so here – it’s a quick install that will sit side by side with your existing browsers, including IE8) and as the “wild story” dust settles serious posts are starting to emerge about the future of IE and browsers in general.

Yesterday a post on the IE blog compared IE9’s 2D rendering example (“Flying Images“) with other major (released) browsers including Chrome 4.1, Safari 4.0.5 and Firefox 3.6. Unfortunately (as pointed out by this slashdot story) the IE blog have chosen to compare a pre release of IE9 with a release of everything else, skipping (for example) Firefox’s nightly versions which already include 2D acceleration.

Sidetrack – Pet Peeve: Along with recent trends to create infographics for everything, more and more sites display pretty graphs showing different measurements and statistics, without showing – in a reproducible way – how they got to them. Kudos to the IE blog for stating that they used xperf, now if only they’d show which perf counters and settings they were hitting…

With a distinct lack of time ahead and no time to properly reproduce the results in xperf, I’ve decided to quickly reproduce the test on my hardware, relying on the software FPS counter (which in the end is king, since that’s what the user is going to see on their screen) and the trusty old “CPU Usage History” counters in Task Manager. I did start using xperf and Windows’ “Performance Monitor”, but the numbers are essentially the same and less confusing.

System Specs: My dev machine (at work) is a relatively souped up machine – Intel Core i7 @ 2.67GHz, 6GB of memory running Windows 7 Enterprise 64-bit.

CPU Usage at Test Start

IE9 Preview

IE9 clocks in with 63 FPS and an extremely low CPU usage. During the test I can see activities on 3 of the 8 virtual cores peaking at around the 20% of each. Average CPU during the test is a flat 3%.

IE9 Doing the Rounds

Low CPU Usage Across all cores

Firefox 20100408 3.7a5pre

Firefox nightly, with 2D acceleration enabled, clocks in at 48 FPS with a little more activity on the CPU (a fluctuating 9-10% with activity on 4 cores peaking at around 30%).

Firefox Nightly Gets Into the Fray

Respectably low CPU usage for Firefox

Chrome 4.1.249.1045 (42898)

Chrome clocks in at 2 FPS with a flat 12% CPU usage caused by heavy usage of one core peaking at just over 80%.

Chrome valiantly tries to keep up

One Core To Rule Them All...

Summary

All in all the behaviour of these browsers on my machine indicates that the IE blog was spot on with their general analysis that hardware acceleration is the way of the future. Chrome’s reliance on one CPU core to achieve rendering in this scenario doesn’t get it very far whereas Firefox and IE9, when taking full advantage of the hardware capabilities of the host cruise through this example with flying colours.

Time will tell how many applications will actually come to rely on this type of hardware acceleration for good performance, but with the rise of Canvas based applications who knows what we may be playing in-browser next?

Looks like it’s back to Google Apps…

Walked into work the other day, only to be greeted by the sight of the above cheerful message on my screens… One wasted day later and it looks like it’s the motherboard that’s gone. *sigh*

Update: Just got my machine back today (9/3) and yup, SATA controllers on the motherboard were fried. So nice to be up and running again with a proper computer!