Closed
Bug 44711
Opened 25 years ago
Closed 23 years ago
Delayed dismissal of "No Plugin Downloader Plugin" dialog causes crash if subsequent page loads.
Categories
(Core :: Layout, defect, P4)
Tracking
()
mozilla1.1alpha
People
(Reporter: benjy, Assigned: serhunt)
References
()
Details
(Keywords: crash)
From Bugzilla Helper: User-Agent: Mozilla/4.73 [en] (X11; U; Linux 2.2.15 i586) BuildID: 20000070508 and 20000070608 When using chofmann's browser buster, the combination of the "No Plugin Downloader Plugin" dialog bug (#43280) and the browser buster's page push unveils a consistent crash bug. If the dialog is not dismissed before the next page begins to load, dismissing the dialog after that point will crash the browser. You can crash Mozilla by dismissing the dialog both when the next page is loading and after it has stopped loading. Note: Since the "plugin downloader plugin" will eventually be installed by either Netscape or Mozilla, this behavior should not be a problem in an of its self. However, since the faulty logic may affect some other situation not yet discovered, it bears investigation. Reproducible: Always Steps to Reproduce: 1) Run the browser buster until the "no plugin downloader plugin" dialog appears -- <http://komodo.mozilla.org/buster/random/random.html> 2) Do not dismiss the dialog, but instead, wait until the browser buster begins to load the next page. 3) Once the next page has started loading, or even after it finishes loading, dismiss the dialog. 4) Watch Mozilla eat flaming death. Actual Results: Mozilla crashes. Nearly always, the browser disappears and the Talkback window appears (about 10-15 times), but once the browser just froze permanently. I was unable to make Mozilla crash using the same procedure with normal alert dialogs (i.e. Alert - "news://comp.windows.x.pex:119/ not found" followed immediately by "failed to connect to server") or the "unknown type: save? open? pick app?" dialog. Expected Results: Mozilla should have continued loading subsequent pages. There are a number my Linux talkback reports from 07/06/2000 which have stack traces for this behavior. Look in the comments for "plugin download" or "delayed dialog dismissal" to identify the appropriate ones. I found references to one of the talkback reports in the crash-data newsgroup summaries. The link given there was http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=13691806 There should be several later reports attached to by email address (benjy at indiansprings.org)
Comment 1•25 years ago
|
||
All of the talkback reports from Benjy have a similar stack that looks like this. over to layout. Incident ID 13691806 nsObjectFrame::Reflow() nsLineLayout::ReflowFrame() nsBlockFrame::ReflowInlineFrame() nsBlockFrame::DoReflowInlineFrames() nsBlockFrame::DoReflowInlineFramesAuto() nsBlockFrame::ReflowInlineFrames() nsBlockFrame::ReflowLine() nsBlockFrame::ReflowDirtyLines() nsBlockFrame::Reflow() nsBlockReflowContext::DoReflowBlock() nsBlockReflowContext::ReflowBlock() nsBlockFrame::ReflowBlockFrame() nsBlockFrame::ReflowLine() nsBlockFrame::ReflowDirtyLines() nsBlockFrame::Reflow() nsBlockReflowContext::DoReflowBlock() nsBlockReflowContext::ReflowBlock() nsBlockFrame::ReflowBlockFrame() nsBlockFrame::ReflowLine() nsBlockFrame::ReflowDirtyLines() nsBlockFrame::Reflow() nsContainerFrame::ReflowChild() CanvasFrame::Reflow() nsBoxToBlockAdaptor::Reflow() nsBoxToBlockAdaptor::Layout() nsScrollBoxFrame::Layout() nsContainerBox::LayoutChildAt() nsGfxScrollFrameInner::LayoutBox() nsGfxScrollFrameInner::Layout() nsGfxScrollFrame::Layout() nsBoxFrame::Reflow() nsGfxScrollFrame::Reflow() nsContainerFrame::ReflowChild() ViewportFrame::Reflow() nsHTMLReflowCommand::Dispatch() PresShell::ProcessReflowCommands() PresShell::FlushPendingNotifications() PresShell::DidCauseReflow() PresShell::ContentAppended() nsDocument::ContentAppended() nsHTMLDocument::ContentAppended() HTMLContentSink::NotifyAppend() SinkContext::FlushTags() SinkContext::DidAddContent() SinkContext::FlushText() SinkContext::AddLeaf() HTMLContentSink::AddLeaf() CNavDTD::AddLeaf() CNavDTD::HandleDefaultStartToken() CNavDTD::HandleStartToken() CNavDTD::HandleToken() CNavDTD::BuildModel() nsParser::BuildModel() nsParser::ResumeParse() nsParser::EnableParser() HTMLContentSink::ResumeParsing() HTMLContentSink::OnStreamComplete() nsStreamLoader::OnStopRequest() nsHTTPFinalListener::OnStopRequest() InterceptStreamListener::OnStopRequest() nsHTTPChannel::ResponseCompleted() nsHTTPServerListener::OnStopRequest() nsOnStopRequestEvent::HandleEvent() nsStreamListenerEvent::HandlePLEvent() PL_HandleEvent() PL_ProcessPendingEvents() nsEventQueueImpl::ProcessPendingEvents() event_processor_callback() our_gdk_io_invoke() libglib-1.2.so.0 + 0xeafa (0x40758afa) libglib-1.2.so.0 + 0x101b6 (0x4075a1b6) libglib-1.2.so.0 + 0x10781 (0x4075a781) libglib-1.2.so.0 + 0x10921 (0x4075a921) libgtk-1.2.so.0 + 0x8c919 (0x40682919) nsAppShell::Run() nsAppShellService::Run() main1() main() libc.so.6 + 0x189cb (0x4024e9cb)
Assignee: asa → clayton
Status: UNCONFIRMED → NEW
Component: Browser-General → Layout
Ever confirmed: true
QA Contact: doronr → petersen
The same crash is on Windows. We should destroy the dialog when the object frame is destroyed. Possible dup of 44169.
OS: Linux → All
True, this crashes, but the dialog in question will only display if the user removes NPNUL32.dll from their plugins directory. Pushing off into future.
Priority: P3 → P4
Target Milestone: --- → M19
the backtrace in 45480 is different, seems to crash in libgklayout.so I marked dup - please "unmark" if i'm wrong.
Comment 10•25 years ago
|
||
I'm not sure whether bug 45480 really is a duplicate. I could reproduce this bug only twice now, and you have to wait until the next page starts loading. With bug 45480, I can click the ok button as soon as I like to make the browser crash. If it is a dup, the URL http://www.xavex.de/ from there is probably a better test case.
Comment 12•24 years ago
|
||
Do all platforms (Linux, Mac) have an npnul plugin? I only see the Windows one in the tree. If this is the case, won't this problem be much worse on those platforms?
Comment 13•24 years ago
|
||
Moving to m0.9. Ed, if you can't get to this in time, please reassign to peterl.
Target Milestone: --- → mozilla0.9
Comment 14•24 years ago
|
||
You know, I don't think this bug is very important, since it doesn't happen unless you don't have the default plugin, which is unlikely. Re-assigning to peterl.
Assignee: edburns → peterlubczynski
Status: ASSIGNED → NEW
Target Milestone: mozilla0.9.1 → mozilla1.0
Comment 15•24 years ago
|
||
Any time you crash, it's important. There is no telling what else is wrong.
Comment 16•24 years ago
|
||
Re-assing to Chris Karnaze. The changs you are planning for ObjectFrame::Reflow will effect this bug. You may fix it in the process. Please let me know if you have any questions.
Assignee: peterlubczynski → karnaze
Comment 17•24 years ago
|
||
That'd explain some of my xlib choffman crashes. Now if only i could find my xul plugin downloader window. It doesn't appear on my computer :-(
Blocks: 79119
Comment 18•24 years ago
|
||
Timeless, did you also have a XUL replacement for about:plugins? See Bug 56863.
Comment 21•23 years ago
|
||
If the default plugin is removed with bug 83754, this should go away.
Depends on: 83754
Comment 22•23 years ago
|
||
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
Comment 24•23 years ago
|
||
moving to 1.1 where the blocker bug is slotted
Target Milestone: mozilla1.0.1 → mozilla1.1alpha
Comment 25•23 years ago
|
||
this is definitely a dup of 44169 which is ready to land *** This bug has been marked as a duplicate of 44169 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•