Closed Bug 140582 Opened 22 years ago Closed 19 years ago

Pressing Ctrl-N should open a new browser when only download dialog is left open

Categories

(Toolkit :: Downloads API, defect)

Product:
Toolkit
Component:
Downloads API
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED DUPLICATE of bug 240696

People

(Reporter: phil, Assigned: bugs)

References

(Depends on 1 open bug)

Details

Sometimes you (accidently) close all browser windows and only a download-window
is still open. Pressing Ctrl-N in this download-window should open a new browser
window.
-> enhancement

but on win32: when mozilla is still present (and when its just the download
window) and you start mozilla while this window is present, does a new instance
of mozilla get created? imho not.. (on linux, it's a new process..)

..do we need this function?
Severity: normal → enhancement
OS: Windows 2000 → All
Hardware: PC → All
a new instance is created - yep - if you don't use "quick launch" it would be
nice - since startup-time would be reduced ...
hmm - startup-time is not the issue - sorry - but it would just be logical to be
able to create a new browser-window even in this dialog without having to look
for the mozilla-icon on the desktop or start-menu.
i'm not a GUI expert..

but isn't it 'ugly' to have a function (new browser window) only acessable via a
shortcut?

When we create a shortcut, there should be imho a button (or menuitem, but this
DIALOG doesn't need a menubar or button  :)) for that..

Because the startup-time is no problem:
wontfix?
 
confirming rfe, ccing UI people.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I've seen this bug somewhere.
Whiteboard: DUPEME
On Mac, the only workaround I've been able to figure out is to send an
AppleEvent to Mozilla.  Mozilla doesn't support the 'reopen' ApplEvent which
clicking on the Dock or application icon will send (bug 90823) so, for most
users, there's no way to get a new navigator window until the download(s)
finish(es).

I think that makes this a bug, not an enhancement, at least for the Mac platform.
Depends on: 171341
QA Contact: sairuh → petersen
Removing enhancement request and adding regression keyword because this actually
used to work for me until recently.
Severity: enhancement → normal
Keywords: regression
Summary: Pressing Ctrl-N should open a new browser. → Pressing Ctrl-N should open a new browser when only download dialog is left open
Well it seems to work on Build 2003071008 on WinXP
WFM on BuildID 2003072404 on WinXP
Perhaps this is Firebird-specific now? Does NOT WFM 20030723/WinXP.
-> Firebird / Downloading
Component: Download Manager → Downloading
Product: Browser → Firebird
QA Contact: petersen → asa
Version: Trunk → unspecified
WONTFIX.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WONTFIX
Care to explain?
VERIFYING obvious WONTFIX bugs.  Filter on firebirdWontFix to filter these bugs.
 I skipped a few that I'm unsure about from their summary and will manually go
through them.
Status: RESOLVED → VERIFIED
Reopening because no reason was given for WONTFIX.
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
i think the problem on this issue is:

if the download windows is the only window left on the screen, the firebird menu
bar is disabled. Therefore, you cannot use the menu to open a new browser
window, and even more, you cannot use keyboard shortcuts fo this action.

Solution: we need a patch to "not disable the menubar".


marking wontfix.
Status: REOPENED → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → WONTFIX
Blake: you still didn't explain why...
This is still a problem.  At the risk of sounding repetitive, reopening because
no reason was given for WONTFIX.

Maybe this bug should be futured and assigned to nobody?  I can't believe 10
years from now Mac users will still have to wait for downloads to finish before
being able to open a new window (the meaning of 'WONTFIX').
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
1. This is not a really regression.
 Ctrl+N only worked with Phoenix0.1 or former.
 We have new download progress window after Phoenix0.2.
 And this decision was made by design.

2. IE doesn't this function.

3. Please do not reopen this bug anymore.

-> WONTFIX
Status: REOPENED → RESOLVED
Closed: 21 years ago → 21 years ago
Keywords: regression
Resolution: --- → WONTFIX
> 1. This is not a really regression.
> Ctrl+N only worked with Phoenix0.1 or former.

I can't even begin to fathom how you manage to classify this as "not a regression".

> And this decision was made by design.

It's really too much to ask for you to give the reasoning of the design decision
? A little matter of "open process". Us lowly triagers of bugzilla don't mind
ukase, but we do like a little bit of explanation. If I were the type to be
insulted, I would be. It's very poor. For starters, the lack of a reason means
we are unable to work out if alternative solutions (such as a button) are
acceptable or not.

Perhaps your reason is "IE doesn't do it" ? (A valid reason to WONTFIX, but
you've yet to state it).

Please clarify.
Verified.

IE doesn't have it, the current dialogs are modelled on IE, ergo the
justification isn't there.  This would also be a matter of fixing the issues
with opening new windows from dialogs, which is probably more effort than its
worth.  A proper startup script on *nix should let you get a new window easily
enough (win32 isn't an issue there) therefore this is just to add a keystroke
that isn't discoverable.  Given the work to do that, its a WONTFIX.  (Unless it
needs to be fixed, Firebird bugs get WONTFIXed instead of vague Future targets.)
Status: RESOLVED → VERIFIED
> We have new download progress window after Phoenix0.2.

Is this a cryptic way of saying the download window no longer blocks new window
creation?  That would be fabulous.

>Perhaps your reason is "IE doesn't do it" ? (A valid reason to WONTFIX, but
you've yet to state it).

Sorry, John, a bug-for-bug emulation of IE is a senseless way to design Mozilla.
 Anyway, on Mac, IE and its successor Safari, do not, in fact, have this bug, so
even if the rationale was considered reasonable it's not true.

>A proper startup script on *nix should let you get a new window easily
>enough (win32 isn't an issue there) therefore this is just to add a keystroke
>that isn't discoverable.

No, it's not.  This is an issue on Macintosh - there's no workaround.  If you
have a 3 hour download going in a download dialog, you're waiting 3 hours until
you can open a new navigator window.  Does it not strike anybody as ludicrous
that this is considered reasonable behavior not worth ever fixing?
Bill: Ctrl-N is not the fix for what you're talking about.  I agree that dialogs
shouldn't block opening new navigator windows, but that is NOT the same bug as this.

bug 90823 is marked fixed, which was the issue you had mentioned at a much
earlier interval.  However, bug 204484 was opened to request porting of the
necessary code to Firebird, and is still open.  The Mac Firebird port is still
rough around the edges, its getting better, but its future is still not clear.
Whiteboard: DUPEME
I'm reopening this since bug 240696 is getting fixed, which is the Firefox
version of this bug.  Ironically, some of the same people who argued against
this bug getting fixed supported the Firefox fix...
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
Thanks for reopening this bug, it's sorely in need of fixing on the Mac
platform.  As was pointed out, if all windows are closed but the download
window, there is no way whatsoever to continue browsing in Firefox without
restarting it.  I've had to fire up Safari a few times to continue browsing
because I'd forgotten I was downloading and closed the main window.....
I think it is a lost tag somewhere...that simple...ill have a looksie if im
right when i turn on my mac at home
As a work-around, I would recommend using Download Manager Tweak to keep the
download manager in a tab instead of a separate window.  This will address being
able to open new windows/tabs when the download manager is the last thing open.
 Personally, I think the download manager being in another tab should be the
default behavior in future versions of Firefox.
This is definitely a bug on OS X.  If you are in the middle of a big download
(say, a large ISO image) and accidently kill all your browser windows, your only
options are to either not browse until the download finishes, or restart FireFox
and kill the download.  This is not acceptable behavior.
Duping to bug that has patch/current info/deps.
Assignee: firefox → bugs
Status: REOPENED → NEW
QA Contact: asa → aebrahim-bmo
Duping to bug that has patch/current info/deps.

*** This bug has been marked as a duplicate of 240696 ***

*** This bug has been marked as a duplicate of 240696 ***
Status: NEW → RESOLVED
Closed: 21 years ago → 19 years ago
QA Contact: aebrahim-bmo → asa
Resolution: --- → DUPLICATE
FYI, on  Mac there is a workaround - you can get a new browser from opening a .html file with Mozilla, 
either by the finder or 'open -a Mozilla file.html' or sending a new window AppleEvent to Mozilla.  It's 
just the GUI that's borked.

At least on SeaMonkey - this bug was a SeaMonkey bug.
v
Status: RESOLVED → VERIFIED
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.