While testing Fx4b2, I can crash Flash consistently with the following steps: 1. Go to youtube and play a video. 2. Use the video's full screen button to go into full screen. 3. Get out of full screen the same way 4. Click on the page to regain tab focus 5. Press Command-shift Flash 10.1.53.64 Reproducible 100% on Mac. I could not reproduce the problem on Linux, nor Win7, nor XP. I used command-shift because I was trying to full screen the browser, but noticed that only command-shift did the trick.
Josh, can you have a look? Sounds like something we need to fix for Firefox 4.
Created attachment 461561 [details] plugin process stack from debug build I can reproduce this easily, this is a stack trace from gdb attached to a debug build.
The problem is that we are trying to serialize an invalid NPCocoaEvent instance. The event is being generated from an nsChildView that is not the plug-in's view: mPluginEventModel = NPEventModelCarbon mIsPluginView = NO Thus the event pointed by nsGUIEvent.pluginEvent is a Carbon event. Then in nsPluginInstanceOwner::ProcessEvent the event is converted to a void* and is treated as a NPCocoaEvent: http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsObjectFrame.cpp#4498 I don't understand how different nsChildView's using different event models is supposed to work. One fix is we can add nsGUIEvent to somehow type pluginEvent and handle the conversion as needed in nsObjectFrame, or make sure pluginEvent never points to a carbon event.
With a recent trunk build I can no longer reproduce the crash. However the first time I press CMD+SHIFT+F, it quickly enters/exits full-screen. After pressing it the second time it stays in full-screen.
Bug 584965 was backed out and now the crash is reproducible again. Adding bug 584965 to dependencies.
(In reply to comment #5) > The event is being generated from an nsChildView that is not the > plug-in's view: > mPluginEventModel = NPEventModelCarbon > mIsPluginView = NO I've noticed this part of the bug, too, and am trying to track it down (it impacts the new JEP). (By the way, the nsChildView in question is the plugin view's superview.) So far I've found the following regression range: firefox-2010-07-15-03-mozilla-central firefox-2010-07-16-03-mozilla-central And I've found that the following patch in this range is what triggered this problem: http://hg.mozilla.org/mozilla-central/rev/a78221e8bde4 This is the patch (from bug 564991) that turned on retained layers. Once I've found out what the connection is, I'll open another bug.
(Following up comment #8) > http://hg.mozilla.org/mozilla-central/rev/a78221e8bde4 By the way, to make this patch compile you'll need to add the following: /** * The address of gColorLayerUserData is used as the user * data pointer for ColorLayers */ static PRUint8 gColorLayerUserData; beneath the following line in layout/base/FrameLayerBuilder.cpp: static PRUint8 gThebesDisplayItemLayerUserData;
Fixed on mozilla-central by the patch in bug 584965.