Closed Bug 76116 Opened 24 years ago Closed 24 years ago

Crash in File-->Exit with embedded plugin om page

Categories

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

x86
Windows NT
defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9

People

(Reporter: serhunt, Assigned: serhunt)

References

Details

Attachments

(2 files)

I tried Flash, QuickTime, the Default plugin. Acrobat does not crash, maybe because it is full-page. Note that a small 'cross' button in the upper right corner closes the applicatin without a crash. I put Plugins as a component but it is likely not. Something with destruction sequence on exit.
*** Bug 75509 has been marked as a duplicate of this bug. ***
I'm not sure what was the logic for creating a new bug and making bug 75509 it's duplicate, but anyways... as I mentioned in bug 75509 , this might have some relation to bug 75554 This indeed happends on exit. Cross button just closes the window, but doesn't exit Mozilla (if you have other windows open). both bug 75509 and bug 75554 have TalkBack report references, which might be of some help, and bug 75509 includes a stack trace.
Confirming this is happening in Windows 2000 with a fresh pull. Av/Sean: this may be releated to your recent check-ins as this is the last thing on the console: nsPluginHostImpl::Observe "quit-application" /software/flash/
Priority: -- → P1
This started to happen after we added exit observer. The observer now fires nsPluignHostImpl::Destroy before nsObjectFrame::Destroy is called. Plugins are destroyed and then in nsObjectFrame::Destroy they are called again causing crash. This can be easily fixed by setting our favorite flag in one more place: NS_IMETHODIMP ns4xPluginInstance::Destroy(void) { // destruction is handled in the Stop call + mStarted = PR_FALSE; return NS_OK; } but even after this it will crash in the base nsObjectFrameSuper::Destroy(...) with the following stack trace. Peter, does it look familiar?
Attached file stack trace for my previous comment (deleted) —
It sort of looks like the stack from bug 66748. cc:ing Kevin for his input. Why is the pluginHostImpl being destroyed before the frames? Is there a way we can delay the Observer to fire only after all the WEBSHELLS have gone away?
Yes, it crashes in nsView::~nsView on mWindow->Destory(). Looks like a ghost window handler. It could probably be fixed by delaying the plugin dll unload which mechanism is already present in nsPluginHostImpl.
One more observation/guess. This only happens when a plugin creates a child window. I have a plugin which doesn't do it and there is no crash. Also images in object frames do not crash.
If setting mStarted=PR_FALSE in the Destroy method fixes the problem then it sounds like ns4xPluginInstance::Stop is not getting called. Perhaps we need to add this line: mActivePluginList.stopRunning(); before the mActivePluginList.shut() call in nsPluginHostImpl::Destroy()?
Sean, I am pleased to tell you that you have excellent eye. This is indeed necessary thing to do and yes, this fixes the crash. Thanks! Nominating 0.9 and patch is coming shortly.
Target Milestone: --- → mozilla0.9
Attached patch first try (deleted) — Splinter Review
sr=waterson
Checked in. Shrirang, when you verify this please check if bug 75509 is now fixed too. Reopen if needed.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
I tried several plugins and the test page in bug 57709 and there is no crash when I quit with the 'download plugin' dialog up. Verif on windows trunk(0417)
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

Creator:
Created:
Updated:
Size: