44711 - Delayed dismissal of "No Plugin Downloader Plugin" dialog causes crash if subsequent page loads.

Status: VERIFIED DUPLICATE of bug 44169

(Core :: Layout, defect, P4)

Description

[Benjy Thomas]

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

[Asa Dotzler [:asa]]

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) 

Comment 2

[karnaze (gone)]

Reassinging to av.

Comment 3

[av (gone)]

The same crash is on Windows. We should destroy the dialog when the object frame 
is destroyed.

Possible dup of 44169.

Comment 4

[leger]

Adding crash keyword.

Comment 5

[edburns]

I'll take this.

Comment 6

[edburns]

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.

Comment 7

[edburns]

I accept

Comment 8

[R.K.Aa.]

*** Bug 45480 has been marked as a duplicate of this bug. ***

Comment 9

[R.K.Aa.]

the backtrace in 45480 is different, seems to crash in libgklayout.so
I marked dup - please "unmark" if i'm wrong.

Comment 10

[Stephan Niemz]

 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 11

[av (gone)]

*** Bug 54650 has been marked as a duplicate of this bug. ***

Comment 12

[Mike Kaply [:mkaply]]

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

[karnaze (gone)]

Moving to m0.9. Ed, if you can't get to this in time, please reassign to peterl.

Comment 14

[edburns]

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.

Comment 15

[Mike Kaply [:mkaply]]

Any time you crash, it's important.

There is no telling what else is wrong.

Comment 16

[Peter Lubczynski]

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.

Comment 17

[timeless]

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 :-(

Comment 18

[Peter Lubczynski]

Timeless, did you also have a XUL replacement for about:plugins? See Bug 56863.

Comment 19

[timeless]

no, just the plugin downloader chrome window. but i can't find it.

Comment 20

[karnaze (gone)]

Reassigning to av.

Comment 21

[Peter Lubczynski]

If the default plugin is removed with bug 83754, this should go away.

Comment 22

[Asa Dotzler [:asa]]

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)

Comment 23

[timeless]

*** Bug 118131 has been marked as a duplicate of this bug. ***

Comment 24

[rubydoo123]

moving to 1.1 where the blocker bug is slotted

Comment 25

[serge (gone)]

this is definitely a dup of 44169 which is ready to land

*** This bug has been marked as a duplicate of 44169 ***

Comment 26

[shrirang khanzode]

I trust serge ! :) verified.