User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de; rv:18.104.22.168) Gecko/2010111021 Camino/2.0.6 (MultiLang) (like Firefox/3.0.19)
Build Identifier: Firefox 4 RC
Firefox 4 should load plugins in a separate process. On Macs with GMA950 graphics, it only loads them in a separate process in 64-bit mode. In 32-bit mode, plugins are loaded in-process.
This means that on a Core Duo machine (that has to use the 32-bit version), the new plugin container is never used.
Steps to Reproduce:
Copied from bug 610526:
1. Run Firefox in 32bit mode
2. Visit Flash enabled web site
3. Look for the lack of plugin-container process in activity monitor
Flash plugin loads "in process".
Flash plugin loads "out of process"
This bug was one of two parts of Bug 610526 (the other being that it didn't work in 64-bit mode either), but that bug has been closed after the bug has been fixed in the 64-bit version and I cannot reopen that bug.
I submitted the bug report with Camino (see user agent string above), but the bug affects Firefox 4 RC.
AFAICT, this is intentional from bug 559441:
"Don't run Flash 10.1 out of process on Mac OS X if machine has an Intel GMA9XX GPU. b=559441 r=bgirard"
That's what I first thought, too, but then why does it work in 64-bit mode? Flash is always 32-bit, so on 64-bit machines with GMA 950, Flash will run in a 32-bit plugin container. And it works just fine.
Is it possible that this execution "in-process" is just a workaround for an old Flash bug that has by now been resolved? Looking closer at the older bug report, that appears to be the case. The workaround could then be removed now.
This would mean users on Core Duo machines (2006) with an old version of Flash couldn't run Flash at all before upgrading to the latest Flash version, but 1.) that would be a good idea anyway and 2.) all users with 64-bit capable Macs -- that's a large majority -- will need to upgrade to the latest Flash anyway, so it wouldn't make much sense to grant those few users of older Macs the privilege to keep the old version (and take away the really useful crash-protection feature from them in return).
Created attachment 518487 [details] [diff] [review]
fix for bug #640601
Don't blacklist Flash >= 10.2
I just realized that a Flash version check is already in the code, because Flash < 10.1 has to be loaded in-process. Therefore it's trivial to check for Flash 10.1, too and enable the plugin container for Flash >= 10.2 on 32-bit machines with GMA 950.
(I have never submitted any patches to Mozilla before, so if I need to do something else, please help ;-)
This is confirmed for NVDIA Geforce GT 330M graphics too.
I don't want to spam everyone, but I'm really a bit frustrated. This is a really important bug, I even took the time to download the FF source and create the fix myself, but still the bug is not even confirmed.
As I said, I have never submitted any patches to Mozilla before, so if I'm doing something wrong, please tell me. The thing that's frustrating me is that I have no idea when or if anything will happen.
Although many Mac users with 32-bit machines are affected by this bug, I doubt many will search bugzilla and vote for this bug, because they are probably no geeks (who have newer machines) and do not realize that the Flash crashes they are experiencing should no longer happen.
So if I just have to be patient for a few more weeks or months, that's no problem, but currently I have the (maybe unfounded, I don't know) feeling that this bug will just sit here "unconfirmed" for years and in the end will be deleted when 32-bit support ends...
I have no idea why this wasn't confirmed. The patch is waiting on Josh to review it; see the review request he set on it. He's been away at the onsite for the last week and a half, but if you don't hear back from him in the next week please comment here?
Comment on attachment 518487 [details] [diff] [review]
fix for bug #640601
I apologize for not reviewing this faster, looks good! Thanks for the patch.
I'll take care of running this through the try server and checking it in.
pushed to mozilla-central