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.