Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20100101 Firefox/10.0 beta 5
Shockwave for Director plugin keeps on crashing on MacOS X 10.6.8.
Steps to reproduce:
1. Start Firefox 10b5 on a clean profile.
2. Go to http://www.shockwave.com/gamelanding/burninrubber3.jsp
After the plugin loads, it will crash or freeze (black screen)
The game should play as expected and the plugin should not crash.
I tested on my home laptop running Beta 4 on 10.6.8 using Version: 11.6.3r633 of the plugin, and I see a black screen as well. If I switch to 32 bit mode the content plays fine.
Vlad - Did this video play okay on the same machine using the previous beta?
The results I get are rather complex. I've tested with today's
mozilla-central nightly and FF 10.0b5 on OS X 10.6.8, with the default
Shockwave plugin (version 10.6.3.633) for OS X 10.6. Though Adobe
claims this is a 64-bit plugin, it's in fact a 32-bit-only plugin.
(There's also a 32-bit/64-bit universal binary Shockwave plugin for OS
X 10.5, which Adobe calls 32-bit only. More about this in a later
All my tests were in 64-bit mode.
With FF 10.0b5 I either get a plugin crash (just about when the music
would have started) or the following error message:
Director Player Error
The file "http://www.shockwave.com/content/
burninrubber3/sis/Cars.cct" is not a Director file.
Then the music keeps playing (and the plugin's display flickers very
badly) until I click OK in the above dialog. Then the music stops and
the display goes black.
With today's mozilla-central nightly I generally don't have any
trouble. But if I've previously gotten the above error with FF
10.0b5, I also keep getting it in today's mozilla-central nightly
until I clear the network cache (Preferences : Advanced : Network).
The 64-bit Shockwave plugin doesn't work in 64-bit mode. You get an error message telling you to restart the browser (in fact to restart Safari) in 32-bit mode :-)
Here are my crash reports:
I can reproduce these problems back to FF 10.0b1, but not in today's beta-debug nightly. I also don't see it in today's aurora nightly.
I tried setting the user-agent string to that used by the FF 10.0 betas, but this made no difference -- this didn't make any of the non-beta builds start having problems.
I can't reproduce this in any beta-debug nightly back to 2011-12-01. There's definitely something fishy going on here ... but I don't know what it is.
The other interesting thing is that some of you are crashing, while in my case on three different machines (two 10.6 and 1 10.7.3 machine) I just get the black screen.
Thinking that this bug might only show up on certain kinds of video hardware, I used the gfxCardStatus app (http://codykrieger.com/gfxCardStatus) to force Firefox to use one or the other of the following two kinds of video hardware:
Intel HD Graphics 3000
AMD Radeon HD 6750M
But I got the same results with either kind of hardware.
If its hardware dependent it would be worth trying with flipping the 'layers.*' prefs (restart required).
The bug doesn't appear to be hardware dependent.
But setting either of the following stops the bug from happening in my tests:
So, Benoit, it looks like your patch for bug 719025 will also fix this bug.
Marcia and Vlad, please try to confirm.
I just tested this on Firefox 10b6 and I didn't get any crash. I didn't changed any prefs in about:config, I tested on a clean install of Firefox with a new profile.
The games are lagging due to my system configuration but there is no crash.
It seems that the crash is fixed?
I don't crash either, testing with FF 10.0b6 on OS X 10.6.8 in 64-bit mode with a clean profile.
I still crash in FF 10.0b5, so it's not that the site has changed.
Benoit, any ideas why we no longer crash?
I landed a fix to disable async plugin rendering on beta 6. Can we test this against trunk? It would be good to know ahead of time if there are any more problems with async plugin rendering.
I've already tested on trunk and didn't have any trouble there.
In fact I've only seen these crashes in FF 10.0b1 through 10.0b5 -- not in *any* nightlies (not even beta-debug ones). Which is very weird, and I can't explain. Though usually this is a sign of a plugin behaving differently depending on which browser it thinks it's running in, changing the user-agent string seems to make no difference.
> I landed a fix to disable async plugin rendering on beta 6.
That explains it.
Considering the comments from above, can I close this bug?
> Considering the comments from above, can I close this bug?
I think so.