14041 - [BLOCKER] Crash when opening download progress dialog

Status: VERIFIED WORKSFORME

(Core :: XUL, defect, P1)

Description

[Bill Law]

Steps to reproduce:

1. Start apprunner.
2. Type in a URL to some unknown content type.  The URL must be http (ftp isn't
working) and the web server must indicatee a mime-type that the browser can't
handle (e.g., application/octet-stream).  The one reference above will work
inside Netscape.
3. Click on "Save File..." on the unknown content dialog.
4. Enter a save as file name, then press OK.

Result: Crash (stack trace below).

Note that in the past I have gotten a strange error loading the chrome URL (see
bug #13121 and bug #13525).  This crash in the widget/window code may be due to
the same root cause.

NTDLL! 77f76148()
nsWindow::Create(nsWindow * const 0x033fc084, nsIWidget * 0x00000000, const
nsRect & {...}, nsEventStatus (nsGUIEvent *)* 0x01b53b63 HandleEvent(nsGUIEvent
*), nsIDeviceContext * 0x032dfd80, nsIAppShell * 0x00000000, nsIToolkit *
0x00000000, nsWidgetInitData * 0x00000000) line 602
nsView::CreateWidget(nsView * const 0x033ff070, const nsID & {...},
nsWidgetInitData * 0x00000000, void * 0x00000000, int 0x00000001) line 1234
DocumentViewerImpl::MakeWindow(void * 0x00000000, const nsRect & {...},
nsScrollPreference nsScrollPreference_kAuto) line 887 + 34 bytes
DocumentViewerImpl::Init(DocumentViewerImpl * const 0x03447d80, void *
0x00000000, nsIDeviceContext * 0x032dfd80, nsIPref * 0x00ab7e10, const nsRect &
{...}, nsScrollPreference nsScrollPreference_kAuto) line 394
nsWebShell::Embed(nsWebShell * const 0x032dfe30, nsIContentViewer * 0x03447d80,
const char * 0x03444d80, nsISupports * 0x00000000) line 867 + 69 bytes
nsDocumentBindInfo::OnStartRequest(nsDocumentBindInfo * const 0x03444dc0,
nsIChannel * 0x034444c0, nsISupports * 0x00000000) line 1887 + 36 bytes
nsChannelListener::OnStartRequest(nsChannelListener * const 0x03444620,
nsIChannel * 0x034444c0, nsISupports * 0x00000000) line 2225 + 43 bytes
nsFileChannel::OnStartRequest(nsFileChannel * const 0x034444c4, nsIChannel *
0x03444120, nsISupports * 0x00000000) line 457
nsOnStartRequestEvent::HandleEvent(nsOnStartRequestEvent * const 0x034456f0)
line 207
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x034456f4) line 144 + 12 bytes
PL_HandleEvent(PLEvent * 0x034456f4) line 509 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00ab6510) line 470 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x018e048c, unsigned int 0x0000c0c0, unsigned int
0x00000000, long 0x00ab6510) line 938 + 9 bytes
USER32! 77e713ed()
00ab6510()

Comment 1

[Peter Trudelle]

These steps are a noop for me using today's opt bits on win98, no progress
dialog, no crash, and no file saved.
reassigning to danm as p1 for m11. Dan, I'm only giving this to you because
window creation is involved, and the bug sounds windows-specific.

Comment 2

[Bill Law]

I tried on Linux and saw what you report.  The Mac crashes in netlib (some kind
of error creating channel/transport) which must have to do with loading the
chrome (since the downloading doesn't commence till after the dialog appears).
So that seems to resemble what I used to see under WinNT (per bugs 13121/13525).

So this seems to be broken lots of different ways!

My theory is necko broke it (since it used to work).

Maybe we should make this another dup of 13525?

Comment 3

[Dan M]

It doesn't actually save the file (is that the subject of another bug?), but it's not crashing
on me today, either.  Is it good for you, too?  (Note: http://law.mcom.com/test.exe is gone; so
I'm not testing under precisely identical circumstances.)

Comment 4

[leger]

Adding crash keyword

Comment 5

[Keyser Sose]

Verified
Platform: PC
OS: Windows 98
Mozilla Build: 2000101020 M18 Trunk Build