27102 - Saving any file hangs

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect, P1)

Description

[Paul MacQuiddy]

I am crashing using today's windows build (win98) when doing saving a file via 
ftp or right-clicking a file and doing save as.

To reproduce:

1. Goto 
ftp://sweetlou/products/client/seamonkey/windows/32bit/x86/2000-02-09-09-M14/
2. clicking on mozilla-win32.zip
3. Click save on dialogue you can barely see.

File picker is thrown up, select save. I then, hang forever and have to stop the 
application manually.

This is seen on windows 20908 build, will check other platforms.

Comment 1

[Judson Valeski]

I get this assert, and an uncontrolable window that I can do nothing with.

NTDLL! 77f7629c()
nsDebug::Assertion(const char * 0x0118f99c, const char * 0x0118f990, const char 
* 0x0118f95c, int 430) line 189 + 13 bytes
nsDebug::WarnIfFalse(const char * 0x0118f99c, const char * 0x0118f990, const 
char * 0x0118f95c, int 430) line 245 + 21 bytes
nsContentTreeOwner::ApplyChromeMask(nsContentTreeOwner * const 0x038685e0) line 
430 + 38 bytes
nsXULWindow::OnChromeLoaded() line 613
nsWebShellWindow::OnEndDocumentLoad(nsWebShellWindow * const 0x0496fd24, 
nsIDocumentLoader * 0x04967290, nsIChannel * 0x04995d30, unsigned int 0) line 
1529
nsWebShell::OnEndDocumentLoad(nsWebShell * const 0x04967b90, nsIDocumentLoader * 
0x04967290, nsIChannel * 0x04995d30, unsigned int 0) line 3216
nsDocLoaderImpl::FireOnEndDocumentLoad(nsDocLoaderImpl * 0x04967290, nsIChannel 
* 0x04995d30, unsigned int 0) line 603
nsDocLoaderImpl::DocLoaderIsEmpty(unsigned int 0) line 494
nsDocLoaderImpl::OnStopRequest(nsDocLoaderImpl * const 0x04967294, nsIChannel * 
0x04995d30, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 
0x00000000) line 438
nsLoadGroup::RemoveChannel(nsLoadGroup * const 0x04967a70, nsIChannel * 
0x04995d30, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 
0x00000000) line 535 + 42 bytes
nsCachedChromeChannel::HandleStopLoadEvent(PLEvent * 0x049957e0) line 401
PL_HandleEvent(PLEvent * 0x049957e0) line 526 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00cf5370) line 487 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x008e033c, unsigned int 49475, unsigned int 0, 
long 13587312) line 975 + 9 bytes
USER32! 77e71820()

Comment 2

[Judson Valeski]

note this happens w/ an HTTP download as well.

Comment 3

[Paul MacQuiddy]

I see this on linux 020908 build also. Http or ftp. Just goto www.mozilla.org, 
right-click n banner and select 'save image as'. File picker comes up, then hit 
OK. Client hangs.

Comment 4

[Paul MacQuiddy]

Don't know if this is relevant, but I get an XML error in the console 'Error in 
file 'chrome://global/content/downloadProgress.xul' line number 10, col 36, 
description not well-formed  title="&downloadWindow.title"

Comment 5

[Daniel (Leaf) Nunes]

marking smoketest blocker.

Comment 6

[Paul MacQuiddy]

Mac doesn't crash on ftp, but it doesn't do anything either. Click on a link 
doesn't bring up a save as dialogue. Doing a http Save Page As brings up the 
file picker, but doesn't download anything, just opens a huge new blank window.

Perhaps there are multiple bugs here.

Comment 7

[don]

Bill is looking at it now ... (but it doesn't look like our bustage)

Comment 8

[Bill Law]

I'm investigating this.  The trace indicates a problem in the url loading arena 
that just happens to appear in this context.  This dialog is a little funky 
because it is being updated in response to network notifications coming in 
asynchronously.  That might account for the slightly different outcome on the 
Mac.

Comment 9

[Simon Fraser [no longer active]]

If I try a Save Page As in the browser, I get an assertion in 
nsContentTreeOwner::ApplyChromeMask() -- domElement is NULL, then a huge blank 
window comes up (the download dialog?), and I'm doomed.

Comment 10

[Bill Law]

If I fix the typo in downloadProgress.xul and back out [e-mail]'s last 
2 changes to downloadProgress.js, things are much better.  Revision 1.6 of the 
.js file just doesn't look right (it dropped a } at the end).

The funny thing is that those changes were checked in on Saturday.

Also note that things are pretty well screwed on Linux (due to bug 26607 which 
is unrelated, I believe).  Your life will be easier if right-click on the link 
to the file to be saved and choose the "Save link as..." context menu option.

I'd like somebody to OK checking in this fix.  We can sort it out later.

I've added Seth and sford3 to the cc: list.

Comment 11

[Bill Law]

Got the OK from leaf, fix has been checked in.

We need to reapply those JS patches I backed out, though.

Comment 12

[Paul MacQuiddy]

verified 2/11, works most of the time :-)