Closing other seamonkey screens when starting save as download causes the download to close

NEW
Unassigned

Status

()

13 years ago
2 years ago

People

(Reporter: steve, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051224 SeaMonkey/1.5a
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051224 SeaMonkey/1.5a

I'm bad at explaining, please see steps to reproduce.

Reproducible: Always

Steps to Reproduce:
1. Set preferences Navigator > Downloads > When starting a download > Open a progress dialogue
2. Browse to start downloading a file (e.g. seamonkey-1.5a.en-US.win32.installer.exe)
3. Close all seamonkey/mozilla windows other than the download dialogue
4. Select 'Save it to disk' and click ok
Actual Results:  
Download dialogue closes and nothing else happens

Expected Results:  
A save as dialogue should appear as usual

I would expect that quick start would need to be disabled for this bug to happen but have not tried.

This is not classed under download manager as I am using the individual download dialogue rather than the download manager itself.

Comment 1

13 years ago
Reproducible with Mozilla 1.8b1, SeaMonkey 1.0b and SeaMonkey 1.5a/20051225.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Document http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-trunk/s
eamonkey-1.5a.en-US.win32.stub-installer.exe loaded successfully
++WEBSHELL 03BCCCE0 == 4
++DOMWINDOW == 8
++DOMWINDOW == 9
WARNING: Using nsIGlobalHistory->nsIGlobalHistory2 adapter., file c:/mozilla/moz
illa/docshell/base/nsGlobalHistory2Adapter.cpp, line 137
WARNING: getting z level of unregistered window, file c:/mozilla/mozilla/xpfe/ap
pshell/src/nsWindowMediator.cpp, line 635
WARNING: getting z level of unregistered window, file c:/mozilla/mozilla/xpfe/ap
pshell/src/nsWindowMediator.cpp, line 635
--WEBSHELL 01F072E0 == 3
************************************************************
* Call to xpconnect wrapped JSObject produced this error:  *
[Exception... "Component returned failure code: 0x80004002 (NS_NOINTERFACE) [nsI
InterfaceRequestor.getInterface]"  nsresult: "0x80004002 (NS_NOINTERFACE)"  loca
tion: "JS frame :: file:///C:/mozilla/mozilla/pure/dist/bin/components/nsHelperA
ppDlg.js :: anonymous :: line 160"  data: no]
************************************************************
###!!! ASSERTION: invalid active window: 'Error', file c:/mozilla/mozilla/embedd
ing/components/windowwatcher/src/nsWindowWatcher.cpp, line 924
WARNING: NS_ENSURE_TRUE(vm) failed, file c:/mozilla/mozilla/docshell/base/nsDocS
hell.cpp, line 3712
WARNING: NS_ENSURE_TRUE(domdoc) failed, file c:/mozilla/mozilla/xpfe/appshell/sr
c/nsXULWindow.cpp, line 1569
###!!! ASSERTION: invalid active window: 'Error', file c:/mozilla/mozilla/embedd
ing/components/windowwatcher/src/nsWindowWatcher.cpp, line 924
Blocks: 312566

Comment 3

13 years ago
How is this related to Bug 28385 and why does this bug block Bug 312566?
Version: unspecified → Trunk
(In reply to comment #3)
> How is this related to Bug 28385 and why does this bug block Bug 312566?

I don't see where bug 28385 is referenced, but I just tested and this wasn't working _before_ bug 312566 landed.  My bad.  Removing dependency.
No longer blocks: 312566

Comment 5

13 years ago
Sorry, I meant could this be related in any way to Bug 28385? 

But I cannot reproduce: I can't close the parent window of the Save As dialog because it is modal. So before the progress dialog is opened at least one browser window is still open.
(In reply to comment #5)
> Sorry, I meant could this be related in any way to Bug 28385?

Related in a broad sense.  Fixing one probably won't have anything to do with the other, though.
> 
> But I cannot reproduce: I can't close the parent window of the Save As dialog
> because it is modal. So before the progress dialog is opened at least one
> browser window is still open.

That's because you're on Linux; your window manager is doing that.  Not sure about Mac, but this bug probably only exists on Win32.

Comment 7

13 years ago
(In reply to comment #6)
> (In reply to comment #5)
> > But I cannot reproduce: I can't close the parent window of the Save As dialog
> > because it is modal. So before the progress dialog is opened at least one
> > browser window is still open.
> 
> That's because you're on Linux; your window manager is doing that.  Not sure
> about Mac, but this bug probably only exists on Win32.

Actually I'm on Win32 (WinXP) with SM trunk 2005122808.
ostgote: I suspect you're not reproducing this correctly; you're actually going too far.  Don't choose Save it to Disk in the "Opening [filename]" dialog _until_ you've closed all other windows.  Step 3 is crucial; if you don't close all other windows, then yes, the filepicker correctly appears and is modal to the browser window.  The bug here is that when all other windows are closed _except_ the "Opening [filename]" dialog, *then* choosing Save it to Disk doesn't yield the filepicker.

Comment 9

13 years ago
This is also reproducible in firefox although there may be a different set of issues there.

==> file handling
Assignee: general → file-handling
Component: General → File Handling
OS: Windows XP → All
Product: Mozilla Application Suite → Core
QA Contact: general → ian

Comment 10

13 years ago
(In reply to comment #8)
Ok, now I see it.
Assignee: file-handling → nobody
QA Contact: ian → file-handling

Updated

2 years ago
Component: File Handling → File Handling
Product: Core → Firefox
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.