Closed Bug 48352 Opened 24 years ago Closed 24 years ago

Can't reopen Mozilla if downloading a file

Categories

(SeaMonkey :: UI Design, defect, P3)

x86
Windows 98
defect

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 50424

People

(Reporter: sockbot, Assigned: law)

References

Details

(Whiteboard: [nsbeta3-][medium][PDTP3][cut 0919])

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m17) Gecko/20000808
BuildID:    2000080804

If I start to download a file using mozilla, then close all the mozilla windows
except the file transfer status window, I cannot open the browser again until
the file has finished downloading.

Reproducible: Always
Steps to Reproduce:
1.Open mozilla and download a file (a large one to give you time)
2.Close all the mozilla windows except the file transfer status window
3.Double click the Mozilla icon to start mozilla (or try to)

Actual Results:  The cursor changed to an hourglass for a split second then back
to the arrow.

Expected Results:  Expected the browser to start.
Well, actually, I think this is somewhat intentional.  You can't reopen Mozilla 
because it thinks an instance of it is already running (since you have that 
download window open).  That was the basis of bug 32112.  The question now is 
whether this is just a wontfix, whether we should close all download windows 
when the last navigator/composer/messenger instance is closed (er, bad idea 
imho), or whether the code to detect if an instance is already running needs to 
be modified such that an open download window doesn't count as a running 
instance.  I'd assume this also happens with windows other than the download 
one (Manage Bookmarks, etc.)  Bill, what do you think?
Assignee: asa → don
Status: UNCONFIRMED → NEW
Component: Browser-General → XP Apps
Ever confirmed: true
QA Contact: doronr → sairuh
tever, do you know if this is intentional?
QA Contact: sairuh → tever
Sairuh: this is intentional, and this is a dupe of a bug I was looking at
yesterday. Mozilla does not open if another instance of it (download, Profile
Manager, etc.) already is open. I will try and find the other bug later.
OK, just me being foolish again. As Blake mentioned before, this was the basis
of 32112.  Check that out, and as law suggested, if this is a problem open a new
RFE bug. I'm going to mark this a dupe due to the similarities between it and
32112. Feel free to correct me if you think I'm wrong.

*** This bug has been marked as a duplicate of 32112 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Well, hold on.  I assume that the next thought the reporter will have when he 
finds out this is intentional is "Why? That's silly"  So I'm going to leave 
this open a little while longer, so law can take a look (although I assume this 
is a dup of something else)
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Summary: Can't open Mozilla if downloading a file → Can't reopen Mozilla if downloading a file
definitely not a blocker, though
Assignee: don → law
Severity: blocker → normal
Status: REOPENED → NEW
The problem (I suspect) is that the code that is supposed to handle the case
where MOzilla is already running isn't working properly.  A DDE request (I'm
talking Windows here, can't say anything about the other platforms) is sent to
the existing application, which is then supposed to open a new window.  The bug
is that a new window isn't opened.

Does it work better if you relaunch with "mozilla -mail"?

I'm marking this nsbeta3.  There are other problems in this area, I think (e.g.,
if there is a browser window, then it always opens a new one, rather than
switching to one already opened; that behavior is different than 4.x and not
what people want).
Status: NEW → ASSIGNED
Keywords: nsbeta3
Making this [nsbeta3+], at least long enough to take a closer look.
Whiteboard: [nsbeta3+]
Priority: P3 → P1
Whiteboard: [nsbeta3+] → [nsbeta3+][medium]
Low profile functionality. Moving to P3.  Adding [PDTP3]
Priority: P1 → P3
Whiteboard: [nsbeta3+][medium] → [nsbeta3+][medium][PDTP3]
bug 50424 closely related
Whiteboard: [nsbeta3+][medium][PDTP3] → [nsbeta3-][medium][PDTP3][cut 0919]
*** Bug 50146 has been marked as a duplicate of this bug. ***
*** Bug 57259 has been marked as a duplicate of this bug. ***
*** Bug 60540 has been marked as a duplicate of this bug. ***
*** Bug 60545 has been marked as a duplicate of this bug. ***
*** Bug 60591 has been marked as a duplicate of this bug. ***
Strangely enough, three of the dups here were filed in only the past 18 hours,
so this starts to smell like a dup-rally.

Either closing the last window (when d/l goes on) should also terminate the
download, possibly with an alert. I believe the behaviour in NC4.* was to
terminate d/l when last window was closed.

OR: ctrl+n shortcut should also trigger from a d/l dialog, to spawn a new
browser window. I guess this latest option would be one the bug-reporters could
live with.
No. NS 4.x did not terminate downloads when the last window was closed.

While Ctrl-N opening a new window would work, it really isn't the best solution. 
Moz should be smart enough to open a browser window for the existing moz 
instance when the user attempts to restart mozilla.
ctrl+n working in the progress dialog is not a suitable alternative, by any 
means.

(1) Ctrl+N doesn't work in any other such dialogs.
(2) That allows keyboard access only.
(3) Not discoverable.
(4) Just masks the real problem here.

*** This bug has been marked as a duplicate of 50424 ***
Status: ASSIGNED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → DUPLICATE
Verifying as a duplicate of bug 50424 
'Run moz while moz is already running --> nothing happens'
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.