Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1a2pre) Gecko/20080817040141 Minefield/3.1a2pre With FlashBlock 1.5.6 and Shockwave 11.0 plugin. STR 1. load http://www.adobe.com/shockwave/welcome/ 2. Click on the Shockwave overlay to unblock the movie 3. move cursor over the movie area 4. a stop watch appears, but the movie is never unblocked. 5. click in the movie leads to crash http://crash-stats.mozilla.com/report/index/e15f1e42-6c57-11dd-b9f0-001cc45a2c28?p=1

The crash happens both on Gecko 1.9.1 (Minefield) and Gecko 1.9.0.2pre (repro'd with Camino 2.0a1pre) This crashlog is from Camino.

Johnny, any thoughts?

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a2pre) Gecko/20080817033619 Minefield/3.1a2pre No crash with Shockwave 10.1.1r16 No crash with Shockwave 11.0r465 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.2pre) Gecko/2008081705 GranParadiso/3.0.2pre No crash with Shockwave 10.1.1r16 No crash with Shockwave 11.0r465 Must be apple specific. The crash is inside the shockwave plugin for which we don't have any symbol information. I'll cc msintov in case the adobe team has any insights.

Johnny, we either need to get this fixed or back out bug 445520 and 438830.

One thing I noticed with Camino 2.0a1pre yesterday (Camino having the ability to turn FlashBlock on/off 'live', without a restart): 1. turn Flashblock on 2. go to url, attempt to unblock the shockwave thingie 3. immediately turn Flashblock OFF (from the Preferences window > Web Features) Result: shockwave thingie loads without a problem, no crash.

Josh, any chance you could help looking into this? We'd need a fix pretty quick here to avoid backing out other fairly critical plugin fixes we took for 1.9.0.2.

Alright, there's been no work done and no update from Josh. We need to backout the patches in bug 445520 and bug 438830.

Bug 445520 and bug 438830 both backed out.

So you brought back a common source of plugin problems (reported something like 50 times only on my site) because of a rare crash that requires several conditions to be met? Argh...

Moving the blocking flag out to 1.9.0.3.

I did some debugging tonight, unfortunately didn't have time to finish but here are some notes: - nsObjectFrame::IsHidden does not check size, so it returns false even if width and height are both 0, not saying that is necessarily wrong but that is why size 0,0 events get sent from nsObjectFrame::CallSetWindow - I haven't checked on Linux to see how often we call SetWindow with 0,0 size but on Mac OS X we probably do it as a result of size setup in nsPluginInstanceOwner::FixUpPluginWindow, which we only do on Mac OS X. I'll try to get more useful information tomorrow.

Any new info?

Johnny or Josh, if you want bug 438830 to get fixed on the branch, we need a fix for this bug.

I'm reassigning this to Josh since Johnny is out. We really need an update here, especially since this is a blocker for 1.9.1.

So this has been confirmed in private email with adobe to be a crash in the shockwave plugin due to us initializing the plugin with a 0x0 pixel sized window, and that's something we didn't use to do. This patch should make us not do that again, and should make this crash go away, at least in this particular case. Josh, any could you test this on a mac with the crashing Shockwave plugin? I'm not able to reproduce this crash, so I can only guess here.

Doesn't seem to work, I get a similar crash inside the plugin's mac event handler with your patch.

Can you tell whether we're still passing the plugin a 0x0 sized window?

... and what the stack is when we do?

Here are a bunch of stack traces, search for "===" in the document to move to different sections. Most traces are from breaking on plugininstance::setwindow where the window has a size of 0x0. One trace is from the actual crash.

This crash is on WinNT. Is this the same or should I file a new bug? <http://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=contains&query=NPSWF32.dll%400x14f779&date=&range_value=1&range_unit=weeks&do_query=1&signature=NPSWF32.dll%400x14f779>

no need for a new bug, but the comment should be updated since it currently claims it is only known to happen w/ shockwave-mac and you've found flash-win. can you use a tryserver to verify the patch fixes it?

> can you use a tryserver to verify the patch fixes it? I think one needs a LDAP password in order to use a tryserver does one not?

> This crash is on WinNT. Is this the same or should I file a new bug? This is probably Bug 464227 since the signature [NPSWF32.dll@0x14f779] matches Bug 464227 Comment 12.

I really think this needs to get fixed before the next beta, if for no other reason than that we should get bug 438830 on the 1.9.0 branch sooner rather than later and it depends on this bug (through a chain of dependencies). Johnny, any update here?

Flashblock is pretty popular (about a million daily users), but only 40K or so on Mac. What percentage of those also use Shockwave, and of that set how many would be willing to ditch either Flashblock or Shockwave to avoid this crash? We'd have to weigh that against the good of fixing bug 438830. I suspect the remainder is a pretty small group.

Forgot the stats url: https://addons.mozilla.org/en-US/statistics/addon/433 Daily use numbers are bogus after Nov 25 because new load balancing hardware isn't reporting (bugs filed). To see the older data change the "Summary" dropdown to one of the active daily users choices.

(In reply to comment #25) > Flashblock is pretty popular (about a million daily users), but only 40K or so > on Mac. What percentage of those also use Shockwave, and of that set how many > would be willing to ditch either Flashblock or Shockwave to avoid this crash? > We'd have to weigh that against the good of fixing bug 438830. I suspect the > remainder is a pretty small group. Flashblock is also part of Camino (and pretty popular). Now that Camino will have a built-in Flashblock white-list UI (bug 371895, ready to land), an affected user can easily unblock a site (Shockwave based games mostly, dunno how many there are out there, I do see my kids regularly accessing such games, mostly on kids.yahoo.co.jp).

(In reply to comment #25) > We'd have to weigh that against the good of fixing bug 438830. I suspect the > remainder is a pretty small group. Unless there's potential that this is only one of many ways to reproduce the crash. We can't be sure and that uncertainty is why I don't like shipping new, known crashes to users of stable releases.

I'm fairly certain that flashblock is simply triggering a crash in the Shockwave plugin that a webpage can trigger as well, in any recent Firefox version. I'm not quite to a point where I can verify that yet, but I should know more tomorrow. I'll also be looking at whether there's something we can do about this w/o adding a hack specifically for Shockwave on the Mac, which I really don't want to do here. Ultimately this is something that should be fixed in the Shockwave plugin, as it's already been confirmed that it is a problem there, just not something that's been triggered a lot before now, with the right combination of browser/extensions.

Ok, so I finally got a build environment set up on my mac and built Firefox. Then I installed the latest version of the Shockwave plugin, which is now newer than what's mentioned in this bug, and tried to reproduce this bug, but no luck. Flashblock blocks the shockwave content, I clicked on it to unblock, it loaded, I clicked around a bunch etc and things seemed to work as expected and no crash. So I'm either not doing the right things to trigger this, or this was actually fixed in a newer version of the Shockwave plugin. Josh said he'd look into this again as well. Any updates Josh?

(In reply to comment #30) Hmm, you're right. The latest Minefield build doesn't crash anymore with FlashBlock 1.5.7.1 and Shockwave 11.0 r470 (latest). I made a Camino build (Gecko 1.9.0.6pre) with the patch for 445520, and indeed, that crash is gone. Camino uses Flashblock 1.5.7. I originally filed this bug with a previous version of Shockwave.

Marking WORKSFORME per above comments then. Please reopen if this is still an issue. Josh, it'd be great if you could triple check too.

Marking fixed1.9.1 to get this off the blocker lists...