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)
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.9
People
(Reporter: serhunt, Assigned: serhunt)
References
Details
Attachments
(2 files)
(deleted),
text/plain
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review |
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. ***
Comment 2•24 years ago
|
||
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.
Comment 3•24 years ago
|
||
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?
Comment 6•24 years ago
|
||
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.
Comment 9•24 years ago
|
||
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()?
Assignee | ||
Comment 10•24 years ago
|
||
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
Assignee | ||
Comment 11•24 years ago
|
||
Comment 12•24 years ago
|
||
sr=waterson
Assignee | ||
Comment 13•24 years ago
|
||
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
Comment 14•24 years ago
|
||
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
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•