User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a5pre) Gecko/20100414 Minefield/3.7a5pre Firefox/3.6 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a5pre) Gecko/20100414 Minefield/3.7a5pre ID:20100416124755 Playing the video at Channel 9 and opening Silverlight options from the Right CLick menu causes a crash. Furthermore, BreakPad doesn't issue a dialog even though the crash is recorded in About:Crashes. This was tested with the latest hourly. Reproducible: Always Steps to Reproduce: 1. Visit the Link above. 2.Start the Video 3. Right Click on the video and Choose "Silverlight" 4. Wait a few seconds without interaction. This bug is not affected by any other Silverlight fixes thus far. It also seems to be random. Sometimes OOPP catches the crash, and sometimes it doesn't. Breakpad Reports: http://crash-stats.mozilla.com/report/index/c46f2672-aee5-4992-847c-a34e92100416 http://crash-stats.mozilla.com/report/index/dba92d3b-7aa6-4a76-8c91-76b822100416 Other crashes were throttled.

I was able to reproduce the crash on 3.6.4(build1) as well.

My crash signatures were different though: http://crash-stats.mozilla.com/report/index/6298b2d2-83c8-4c5c-8cf9-e0abd2100416

After poking around with the STR @ MozillaZine it seems that the Silverlight options window does not have to be open for this to trigger. Revised STR: 1. Visit the Link above. 2. Start the Video. 3. Right Click on the video. 4. Left Click anywhere to dismiss the menu item. 5. Wait a few seconds without interaction. I also noticed that the cursor does not transition back to a normal pointer from the link select hand once that menu opens.

I'll record. There seems to be two different issues here, the hang (which kicks off hang detector correctly, I think), and then a browser-side crash without crash reporter. Ugh. And FWIW, this is not fixed in the the latest m-c nightly, so it's not a dup of bug 559384.

hang -> sync WM_CONTEXTMENU sent from child to parent window. I think we've accumulated too many of these if statements here, I'm going to put together a broader patch that moves all these reply message handlers into a single case statement.

The freeze was in delayed destroy while walking the list of destruction guards. There was a guard in the list that was invalid. Benjamin, are you going to track that down in your recording or do you want me to take a look?

(In reply to comment #7) > The freeze was in delayed destroy while walking the list of destruction guards. > There was a guard in the list that was invalid. Benjamin, are you going to > track that down in your recording or do you want me to take a look? er, sorry, "The crash.."

will land tomorrow, tree is closed for the evening for IT maintenance.

Verified, STR no longer produces the crash. Cheers!

The additional crash is now bug 560213, and is probably responsible for the whole class of signatures [@ operator new(unsigned int) | *]

Comment on attachment 439703 [details] [diff] [review] revamp w/fix undoing change, we still need patch approval.

Comment on attachment 439703 [details] [diff] [review] revamp w/fix a=LegNeato for 1.9.2.4

1.9.2: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/18c557af0df4 relbranch: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/f826fd0b3984

Verified for 1.9.2 using the repro steps in comment 0 using today's 1.9.2 build: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.5pre) Gecko/20100423 Namoroka/3.6.5pre. Crash occurs in build 1 of 3.6.4 on same machine.