Let’s Mix Critical Security Patches and Major Architecture Changes and see What Happens.

Is re-architecting key functionality on an N.n.n release unusual?
“Yes, this was an unusual release, and an experiment in shipping new features quicker than our major release cycle normally allows.”
On version 3.6.n, plugins shared process space. On 3.6.n+1, plugins do not.

The experiment appears to have suffered a setback.

The problem?
“…we are seeing an increasing number of reports that some users are unable to play Farmville, because Farmville hangs the browser long enough for out timeout to trigger and kill it.”
Apparently the “crashed plugin” timer needs to be long enough that Farmville can finish loading. Ten seconds isn’t long enough.

How did they originally arrive at a 10 second timeout?
“Originally a 10s timeout made a lot of sense considering that we had no actual data to go with.”
It looks like none of the Mozilla developers or testers play Farmville, or they’d have caught the problem prior to release.

Why make major changes to a minor release? To improve the customer experience, of course:
“Mozilla is always looking for more ways to bring users valuable features and improvements as quickly as possible. Crash protection offers significant stability enhancements, and product drivers wanted to make it available to Firefox users as soon as possible.”
The net effect of this is probably minor. Enterprises that actually have to spend real money and real staff time to roll out new code to some of the hundreds of millions of desktops that use Firefox can skip this release, and we’re all using the product for free so our time doesn’t count and we can’t complain.

I’m not a fan of mixing high priority security fixes with new functionality. Any change in functionality introduces the possibility that a high priority security patch/fix can’t be implemented because it breaks existing downstream dependencies.