Closed
Bug 77714
Opened 23 years ago
Closed 23 years ago
Mac crashes when closing after java site.
Categories
(Core Graveyard :: Java: OJI, defect)
Tracking
(Not tracked)
VERIFIED
WORKSFORME
People
(Reporter: junruh, Assigned: nezbo)
References
()
Details
(Whiteboard: oji_working)
Attachments
(1 file)
749 bytes,
patch
|
Details | Diff | Splinter Review |
1.) Visit a site with java like http://www.sj-downtown.com. 2.) Click Back, then on File, Quit. What happens: The browser crashes.
Updated•23 years ago
|
QA Contact: shrir → junruh
Assignee | ||
Comment 1•23 years ago
|
||
The _particular_ variation works, perhaps due to today's fixes for bug #76936 and bug #79872. However, bug #81631, quitting with an applet running, still exists. Man, loading http://www.mozilla.org/quality/browser/front-end/testcases/oji/test2.html takes forEVER now.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Assignee | ||
Comment 2•23 years ago
|
||
The bug is back today (with a late build from 21May) but with a different crash signature. Probably all the LiveConnect work and lazy-loading of Java stuff getting hashed out. Last few calls in the stack crawl: nsPluginHostImpl::Destroy()+34 nsActivePluginList::stopRunning()+48 MRJPluginInstance::SetWindow(nsPluginWindow*)+28 MRJContext::setWindow(nsPluginWindow*)+8c MRJContext::synchronizeClipping()+a4 .... then crash in NQDSetRectRgn
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Assignee | ||
Comment 3•23 years ago
|
||
when quitting after close, nsActivePluginList::stopRunning() calls MRJPluginInstance::SetWindow() with a nil window a second time (the first was during close of window) but the attempted MRJPlugin.cpp;line #743 'mContext->setWindow(pluginWindow);' is doomed to failure as this->mContext is nil by now.
Assignee | ||
Comment 4•23 years ago
|
||
oops, I meant that SetWindow is called a second time. nsActivePluginList::stopRunning isn't involved when the window gets closed. In any case, mContext has been set to null, and MRJPluginInstance::SetWindow() and MRJPluginInstance::Stop() (which have already been called) aren't expecting that. As a workaround, putting 'if (mContext)' checks in those two routines prevents today's 77714 crash.
Assignee | ||
Comment 5•23 years ago
|
||
Assignee | ||
Comment 6•23 years ago
|
||
bug has disappeared in build from morning of 5.29.01
Updating Status Whiteboard to indicate a bug actively being worked on by Terry.
Whiteboard: oji_working
Assignee | ||
Comment 8•23 years ago
|
||
stack crawl has now changed (6/14 am build) to nsJVMManager::Release()+18 nsJVMManager::Internal::Release()+48
Assignee | ||
Comment 9•23 years ago
|
||
Both bug 77714 and bug 81631 have gone away on my 2001062210 build. Perhaps the LiveConnect stuff has gotten settled.
Reporter | ||
Comment 10•23 years ago
|
||
*** This bug has been marked as a duplicate of 81631 ***
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → DUPLICATE
Assignee | ||
Comment 11•23 years ago
|
||
It is not a duplicate, though. Using recent builds, bug 77714 still happens on one of my B&W G3's but not on my iMac. Bug 81631 seems to have disappeared. In any case, the crash signatures of the two are completely different, and 77714 is patchable, though I've no satisfying solution.
Reporter | ||
Comment 12•23 years ago
|
||
Reopening. Not really a dupe, and still reproducible.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Reporter | ||
Comment 13•23 years ago
|
||
Worksforme with the 7/25 Mac RTM build.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•