Closed Bug 104236 Opened 23 years ago Closed 23 years ago

crash when flash context menu visible when page unloads

Categories

(Core Graveyard :: Plug-ins, defect, P3)

x86
Windows 98
defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.9

People

(Reporter: tuukka.tolvanen, Assigned: peterl-bugs)

References

()

Details

(Keywords: crash, topembed, Whiteboard: [same problem in 4.x])

Attachments

(2 files, 2 obsolete files)

Reproducible: Always Steps to Reproduce: 1. http://www.tomshardware.com/ 2. click on reload or a bookmark or link or whatever 3. get a context menu from one of the flash ads while the page is still visible ...crash when page disappears MOZILLA caused an invalid page fault in module <unknown> at 0000:0092b9c9. Occurs on on Windows 98 with the following builds: 2001101103-0.9.5 TB36563438Q 2001101103-trunk TB36567688G
confirming with win2k build 20011011.. a useless stack from my debug: 06857d8c() 0012fc90() 06857341() USER32! 77e030e0() USER32! 77e05824() nsAppShellService::Run(nsAppShellService * const 0x03940d10) line 457 main1(int 2, char * * 0x003577d0, nsISupports * 0x00000000) line 1291 + 32 bytes main(int 2, char * * 0x003577d0) line 1619 + 37 bytes mainCRTStartup() line 338 + 17 bytes KERNEL32! 77e87d08()
Keywords: crash
Confirming on NT40. No stack trace is available with my debug build.
We probably need to do something like force the native context menus to rollup when the plugin instance owner is being destroyed. Maybe Chris or Rod can point out an example of how to do this?
Likely not our bug. This also happens with 4.x. Use Ctrl-R to reload the page otherwise your mouse may be not fast enough to get back to the Flash ad before the page disappears.
*** Bug 100538 has been marked as a duplicate of this bug. ***
can someone check if this is really a flash plugin issue or mozilla issue?
Andrei mentioned above that this is not a mozilla bug probably(happens in 4.x 2) ). Am marking invalid .
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
I don't think this is a Flash Player bug. I can get a similar crash with the Quicktime plugin. 1. Go to www.apple.com 2. CTRL+R 3. Quickly right click on the Quicktime movie 4. Quickly select "About Quicktime Plug-in" 5. Crash! QUICKTIME! 62b0a9f3() QUICKTIMEWEBHELPER! 62c88ddb() 43003d00()
Hm... could be related to bug 116232.
*** Bug 123896 has been marked as a duplicate of this bug. ***
I am reopenning the bug. Attributing to third party is not sufficient here. Or at minimum we need to know that flash is aware and is working on a fix. Can we not handle this more gracefully?
Status: RESOLVED → REOPENED
Keywords: edt0.9.4
Resolution: INVALID → ---
Keywords: topembed
I'm trying to see if we can send the plugin a message to roll up the context menu, but no luck so far. BTW, this ALSO happens in 4.x.
Peter is this a Flash bug? Shrirang is this reproducible in IE?
no, IE is fine.
Attached image spy++ log (deleted) —
I'm not 100% sure, but what I think is happening is ::TrackPopupMenu() is called by the plugin and then we go around and destroy their window AND unload their DLL from memory. It then looks like some invalid memory is being referenced when we crash. It tried to use ::SendMessage() at the time we destroy the plugin instance to send a left button click OUTSIDE the window, but that didn't seem to help. The attachment is a screenshot of Spy with this hack.
Blocks: 123367
O94 is closed. Minusing KW
Keywords: edt0.9.4edt0.9.4-
Nothing that I've tried works so far. I'm open to new ideas. ...waiting to hear back from Macromedia
Assignee: av → peterl
Status: REOPENED → NEW
Priority: -- → P3
Whiteboard: [same problem in 4.x]
Target Milestone: --- → mozilla1.0.1
I've done a little digging and here's what i've discovered. We encounter this crash whenever Any 4.x PLUGIN enters a sub-event-loop during a page transition. typically, this sub-event-loop is a context menu... It turns out that the document is destroyed in response to a PLEvent (I believe it is the proxied call to nsIStreamListener::OnStopRequest which originated on the necko thread...). If this PLEvent is processed by the plug-in's sub-event-loop, then we are in BIG trouble... This is because part of the plugin destruction involves unloading the plugin DLL. Unfortunately, codepages from the plugin DLL are currently active because we are inside of the plugin's sub-event-loop :-( Are you starting to see where this is going ;-) Document destruction proceeds and the plugin DLL is unloaded, unfortunately when we return from processing the PLEvent the code-pages containing the sub-event-loop are unloaded and we crash! As far as i can see, the only way to protect against this situation is to defer plugin unloading until we are at a 'safe, known base state' where we KNOW that no plugin code is on the call stack !! I'm not familiar enough with plugin unloading to really understand where this 'safe, known base state' is :-( However, a first attempt might be to trigger plugin unloading off of a PLEvent... I *think* that by the time the PLEvent is processed, the plugin will have been destroyed and none of its code pages should be actively on the call stack. In addition to this, i believe that on Win32 we need to call ::EnableWindow(pluginWnd, FALSE) as part of the plugin destruction process... This causes any sub-event-loops caused by context menus, or dragging to be exited. Refer to http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/windows_92sl.asp for more information... It's interesting to note that on IE, this situation causes the page transition to be deferred until the plugin leaves it sub-event-loop.
Attached patch working patch? (obsolete) (deleted) — Splinter Review
Rick, thanks for the analysis! Here's a possible patch to unload the plugin library off a PLEvent. This alone seems to prevent the crash.
Attached patch slightly cleaner patch (obsolete) (deleted) — Splinter Review
Please review/comment
Attachment #69263 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Keywords: patch, review
Target Milestone: mozilla1.0.1 → mozilla0.9.9
This looks good to me. Do you think it would make sense to wrap the call to PR_UnloadLibrary(...) inside of: NS_TRY_SAFE_CALL_VOID(PR_UnloadLibrary(mLibrary), nsnull)); this way, if the plugin GPFs during DLL unload, we don't crash... i passed 'nsnull' as the 'aLibrary' argument because i figured that the plugin had already been removed from the mPluginsList... So, we couldn't report the name of the plugin... but we wouldn't crash either ;-) -- rick
Attached patch updated patch (deleted) — Splinter Review
Yeah, I think using plugin saftey here would be nice. I also fixed another case of PR_UnloadLibrary(). Please rsr=
Attachment #69279 - Attachment is obsolete: true
Attachment #69369 - Flags: superreview+
Lets push this to the trunk
Comment on attachment 69369 [details] [diff] [review] updated patch r=av
Attachment #69369 - Flags: review+
patch in trunk, marking FIXED
Status: ASSIGNED → RESOLVED
Closed: 23 years ago23 years ago
Keywords: review
Resolution: --- → FIXED
Great! This appears to also fix a related problem on linux, where in the same situation it would not crash, but the flash context menu would be left hanging on top of all windows until Mozilla was closed. Now it goes away nicely. neat :)
requesting edt0.9.4+
not crashing anymore. I tried reloading ,clicking links ( and loading flash context menu simultaneously). working fine on 0306 trunk. V
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: