Closed Bug 240696 Opened 20 years ago Closed 12 years ago

cannot open new browser window if the only window open is the download manager

Categories

(Firefox :: Keyboard Navigation, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: linuzonix, Assigned: steffen.wilberg)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Keywords: fixed-aviary1.0)

Attachments

(1 file, 11 obsolete files)

16.07 KB, patch
dao
: review-
Details | Diff | Splinter Review
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040324 Firefox/0.8.0+
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040324 Firefox/0.8.0+

Suppose you start a download and then close all browser windows except from the
download manager window. You can not open a new browser window anymore unless
you close the download manager (thus quiting your downloads).

Reproducible: Always
Steps to Reproduce:
1. Open the download manager
2. Close all browser windows
3. You can't open any new browser windows



Expected Results:  
There should be a menu on the download manager window with an option to open a
new  browser window.
this is more dependent on implementing a sane startup script.  Opening windows
from dialogs in problematic in many cases, so that's probably not viable.
Assignee: firefox → bugs
Component: General → Downloading
Depends on: 177996
QA Contact: aebrahim
-> NEW, this is absolutely valid.
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 228726 has been marked as a duplicate of this bug. ***
Able to browse under different profile. The Profile Manager insists that the
original profile is locked (i.e. It thinks the browser is still open.) 
I have this patched on my own system here is the diff:

In toolkit.jar file /content/mozapps/downloads/download.xml:

<handler event="keypress" key="n" action="parent.window.open('');"
modifiers="control"/>

One UI option you might want to consider is adding a New Window button to the
download manager to make it more obvious to new users that it is possible to
open new windows still. 

In toolkit.jar file /content/mozapps/downloads/downloads.xul:

<separator id="commandBarSeparator"/>             
<button id="newWindowButton" 
    style="margin: 0px; -moz-user-focus: ignore;"
    label="New Window" accesskey="n" 
    oncommand="parent.window.open('');"/>

(note: style part would be moved to CSS file in skin of course).

--Mark
This also happens under MacOSX!
OS: Linux → All
Hardware: PC → All
It might be easy for a novice to notice this bug. Nominating for 1.0
Flags: blocking-aviary1.0?
Not stop ship although may reconsider with a simple patch. 
Flags: blocking-aviary1.0PR-
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0-
Attached patch Allow Ctrl+N from DM window (obsolete) — Splinter Review
Mark Bokil's change from comment 5 in patch format. Does not include the
button.
No longer depends on: 177996
Flags: blocking-aviary1.0PR- → blocking-aviary1.0PR?
Whiteboard: [have patch]
Comment on attachment 157465 [details] [diff] [review]
Allow Ctrl+N from DM window

that isn't localizable.  You need to define the accesskey in the appropriate
dtd file.
Attachment #157465 - Flags: review?(bugs) → review-
reverting flags based on current status of patch.

As a note, launching from whatever shortcut should now work fine on all
platforms now that bug 177996 is fixed, minimizing the importance of this.  Its
almost an enhancement at this point, since its not needed.
Severity: normal → minor
Depends on: 177996
Flags: blocking-aviary1.0PR? → blocking-aviary1.0PR-
Whiteboard: [have patch]
Attached patch Patch v2 (obsolete) — Splinter Review
Allows Ctrl+N from DM, localizable, adds strings for a button if needed in the
future.
Attachment #157465 - Attachment is obsolete: true
Comment on attachment 157475 [details] [diff] [review]
Patch v2


>+<!ENTITY cmd.newWindow.label              "New Window">
>+<!ENTITY cmd.newWindow.accesskey          "W">

There's no need to add these strings.  We're not going to add a button for
this.

r=me with those removed.
Attachment #157475 - Flags: review?(mconnor) → review+
Attached patch Patch v2 (comments addressed) (obsolete) — Splinter Review
Addressed comments
Attachment #157475 - Attachment is obsolete: true
Comment on attachment 157497 [details] [diff] [review]
Patch v2 (comments addressed)

Carrying over r=mconnor per comment 13
Attachment #157497 - Flags: review+
Attachment #157497 - Flags: approval-aviary?
*** Bug 257589 has been marked as a duplicate of this bug. ***
This problem appears on Mac OS X as well, where you can't open the File menu when only downloads is 
open. Making it accessible would fix this bug on Mac, since the menubar is always visible. A new 
browser window should also appear when you click on the FireFox icon (This happens when no windows 
are open but doesn't happen when only the downloads window is open)
Comment on attachment 157497 [details] [diff] [review]
Patch v2 (comments addressed)

a=asa for branch checkin.
Attachment #157497 - Flags: approval-aviary? → approval-aviary+
Can someone checkin this patch?
Whiteboard: [needs to be checked in]
is parent ever null? what if the dlmgr is opened from the unknown content type
handler? just a q. 
Works fine for me when it's opened from the unknown content type dialog.
*** Bug 260269 has been marked as a duplicate of this bug. ***
Checked in on the aviary 1.0 branch:

Checking in locales/en-US/chrome/mozapps/downloads/downloads.dtd;
/cvsroot/mozilla/toolkit/locales/en-US/chrome/mozapps/downloads/Attic/downloads.dtd,v
 <--  downloads.dtd
new revision: 1.1.2.6; previous revision: 1.1.2.5
done
Checking in mozapps/downloads/content/download.xml;
/cvsroot/mozilla/toolkit/mozapps/downloads/content/download.xml,v  <--  download.xml
new revision: 1.11.6.1; previous revision: 1.11
done

Should this be checked in on the trunk is well?
Comment on attachment 157497 [details] [diff] [review]
Patch v2 (comments addressed)

This was approved before the l10n freeze, it is not approved now, because it
affects l10n. Why can't you just use the entity from browser.dtd, instead of
creating a new one? I have asked kherron to back out the checkin on the aviary
branch. If someone wishes to prepare a patch which uses the browser.dtd entity,
that should be easy to approve.
Attachment #157497 - Flags: approval-aviary+ → approval-aviary-
Backed out per the sheriff. Sorry about that.



Checking in locales/en-US/chrome/mozapps/downloads/downloads.dtd;
/cvsroot/mozilla/toolkit/locales/en-US/chrome/mozapps/downloads/Attic/downloads.dtd,v
 <--  downloads.dtd
new revision: 1.1.2.7; previous revision: 1.1.2.6
done
Checking in mozapps/downloads/content/download.xml;
/cvsroot/mozilla/toolkit/mozapps/downloads/content/download.xml,v  <--  download.xml
new revision: 1.11.6.2; previous revision: 1.11.6.1
done
Sorry about that, I should have done that in the first place.
Attachment #157497 - Attachment is obsolete: true
Comment on attachment 160061 [details] [diff] [review]
Patch v3 (checked into aviary, backed out from trunk)

OK, great
Attachment #160061 - Flags: review?(mconnor)
Attachment #160061 - Flags: review+
Attachment #160061 - Flags: approval-aviary+
Checked in the new patch on the aviary branch:

Checking in download.xml;
/cvsroot/mozilla/toolkit/mozapps/downloads/content/download.xml,v  <--  download.xml
new revision: 1.11.6.3; previous revision: 1.11.6.2
done
Checking in on the trunk:

Checking in download.xml;
/cvsroot/mozilla/toolkit/mozapps/downloads/content/download.xml,v  <--  download.xml
new revision: 1.12; previous revision: 1.11
done

Resolving FIXED.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Keywords: fixed-aviary1.0
Whiteboard: [needs to be checked in]
OK, I'm reopening and backing this out on trunk. This 1) has a bad dependency of
toolkit/ on browser/ and 2) doesn't make any sense in tbird and other future
apps. We need something like an app-specific overlay of the download manager to
do this properly. since tbird apparently doesn't use the download manager on the
branch, mconnor decided to leave this on the branch as a one-time hack
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
The dependency is only because I used the the entity from browser.dtd, like you
asked. After the l10n freeze it can be changed back to the original way, thus
removing the dependency. As for Thunderbird, can it not just be ifdefed out? I
suppose that may not be as elegant but it would definitely work.

Please forgive my lack of knowledge of the code, I'm just throwing out some
ideas here.
The dependency problem really has nothing to do with the DTD, it is that
Control-N should only open a new window in Firefox, not in tbird or any other
embedding app that uses the new toolkit. #ifdefs are not acceptable because they
mean we cannot use the same toolkit/libxul/xulrunner binary for all the apps in
question.
Should this possibly be upgraded from minor? I would think that this is very
important to fix before 1.0 as I wouldn't have remembered I could press CTRL + N
but for the comments in this bug, and I wouldn't have wanted to cancel my 600MB
download when it's 50% done just to get a browser window back. I can see new
users becoming pretty confused when the Profile Manager appears instead of the
expected browser window.
The modifier has to be "accel", not "control", so that Mac users can use Cmd+N.
And the key should go into downloads.xul instead of downloads.xml. See bug 263146 .
Attached patch Patch v4 (no l10n change) (obsolete) — Splinter Review
Made changes brought up in comment 34.
Attachment #160061 - Attachment is obsolete: true
Oops, forgot to remove what was there before.
Attachment #161434 - Attachment is obsolete: true
Flags: blocking-aviary1.0mac?
Whiteboard: remaining bug: use "accel" instead of "control" to work on Mac
Removing fixed-aviary to address comment 34. If attachment 161436 [details] [diff] [review] is checked in
this will be fixed.
Keywords: fixed-aviary1.0
Attachment #161436 - Flags: review?(bugs) → review?(bsmedberg)
This bug seems to have an aviary branch checkin associated with it. If this has
landed on the aviary branch (as much as it's going to for 1.0) can you please
add the "fixed-aviary1.0" keyword? Thanks.
Adding fixed-aviary1.0 again since this is functional at the moment and the
latest patch isn't necessary per se. The latest patch addresses the issues in
comment 34, and it needs to be checked in for this to work for Mac users.

Additionally, issues raised in comment 30 are to be addressed before this is
truly fixed.
Nobody will look at this bug if it has the fixed-aviary1.0 keyword. Removing it
again since it's not completely fixed, see comment 34, and the whiteboard.
Keywords: fixed-aviary1.0
OS: All → MacOS X
Hardware: All → Macintosh
Comment on attachment 161436 [details] [diff] [review]
Patch v4.1 (followup, mac support)

Trying Blake for review
Attachment #161436 - Flags: review?(bsmedberg) → review?(firefox)
Isn't this a very very special case of bug 239218 ?
(In reply to comment #42)
> Isn't this a very very special case of bug 239218 ?

No, that is a mac specific bug that has to do with menus. This bug has to do
specifically with the download manager and is cross platform.
OS: MacOS X → All
Hardware: Macintosh → All
Version: unspecified → 1.0 Branch
*** Bug 267018 has been marked as a duplicate of this bug. ***
Confirmed on latest nightly (31.10.2004).
*** Bug 268227 has been marked as a duplicate of this bug. ***
Whiteboard: remaining bug: use "accel" instead of "control" to work on Mac → remaining bug: use "accel" instead of "control" to work on Mac / see bug 21296 for related (but not same) issue
Comment on attachment 161436 [details] [diff] [review]
Patch v4.1 (followup, mac support)

Almost zero chance for 1.0. But who knows.
Attachment #161436 - Flags: review?(firefox)
Attachment #161436 - Flags: review?(bugs)
Attachment #161436 - Flags: approval-aviary?
-> Gavin.
Assignee: bugs → gavin_sharp+bugzilla
Status: REOPENED → NEW
Flags: blocking-aviary1.0mac?
Comment on attachment 161436 [details] [diff] [review]
Patch v4.1 (followup, mac support)

Too late for 1.0
Attachment #161436 - Flags: review?(bugs)
Attachment #161436 - Flags: approval-aviary?
Attachment #161436 - Flags: approval-aviary-
*** Bug 268250 has been marked as a duplicate of this bug. ***
*** Bug 268297 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Landing of aviary branch has checked this patch back in, does it need to be
reversed out?
Keywords: aviary-landing
(In reply to comment #52)
> Landing of aviary branch has checked this patch back in, does it need to be
> reversed out?

The fix that was checked into aviary wasn't ideal and didn't work on the Mac.
What's left to be done is check in the follow up patch.
Comment on attachment 161436 [details] [diff] [review]
Patch v4.1 (followup, mac support)

Addresses observations made in comment 34.
Attachment #161436 - Attachment description: Patch v4.1 (no l10n change) → Patch v4.1 (followup, mac support)
Attachment #161436 - Flags: approval-aviary- → review?(mconnor)
Attached patch Diff -up8 (obsolete) — Splinter Review
Diff -up8 of previous patch.
Yes, please back this patch out of the trunk, until a real solution can be found.
Attachment #161436 - Flags: review?(mconnor) → review-
Attachment #161436 - Attachment is obsolete: true
Attachment #167939 - Attachment is obsolete: true
Backed out again
Keywords: aviary-landing
Attachment #160061 - Attachment description: Patch v3 (no l10n change) → Patch v3 (checked into aviary, backed out from trunk)
Keywords: fixed-aviary1.0
Whiteboard: remaining bug: use "accel" instead of "control" to work on Mac / see bug 21296 for related (but not same) issue → trunk solution: see comment 30 / see bug 21296 for related issue
Version: 1.0 Branch → Trunk
Whiteboard: trunk solution: see comment 30 / see bug 21296 for related issue → [start] trunk solution: see comment 30 / see bug 21296 for related issue
*** Bug 283249 has been marked as a duplicate of this bug. ***
I was curious as to the status of this bug. I read that FireFox was the best
browser out there. So I downloaded it yesterday, everything worked great. I
closed all my windows except the download manager and walla, not one item on the
menu bar worked. I'm running OS 10.3.8 and I must say, this will keep me from
using FireFox 100%. I still will have to use Safari seeing how it is a good
solid and stable program.

Any new developments I should be aware of?
*** Bug 284766 has been marked as a duplicate of this bug. ***
Conforming this bug for MacOS X and Firefox 1.0.1
The problem also occurs when a URL is being opened by passing an event from an
other application (for example you click on a URL in your email application
which opens Firefox by default with a new window on that URL).
For Mac, having the menus actually working sanely in 1.1 will fix this, I believe.
Depends on: 239218
*** Bug 140582 has been marked as a duplicate of this bug. ***
I assume we want at least the open-help keys as well.
Priority: -- → P2
Target Milestone: --- → Firefox1.1
Attached patch Overlay DM (obsolete) — Splinter Review
Attachment #184235 - Flags: review?(mconnor)
Comment on attachment 184235 [details] [diff] [review]
Overlay DM

This patch:
- Moves downloadManagerOverlay.xul to downloadManagerOverlayMac.xul
- Changes downloadManagerOverlay.xul to add the help and new window shortcuts
(f1 and Ctrl+N)
- Overlays the DM with either downloadManagerOverlay.xul  or
downloadManagerOverlayMac.xul, accordingly
Whiteboard: [start] trunk solution: see comment 30 / see bug 21296 for related issue → [patch-r?] trunk solution: see comment 30 / see bug 21296 for related issue
Comment on attachment 184235 [details] [diff] [review]
Overlay DM

> #ifdef XP_MACOSX
>-*       content/browser/downloadManagerOverlay.xul    (content/downloadManagerOverlay.xul)
>+*       content/browser/downloadManagerOverlayMac.xul (content/downloadManagerOverlay.xul)
This should be (content/downloadManagerOverlayMac.xul), I guess.

>+    <key id="key_help"   keycode="&openHelp.commandkey;"
>+         oncommand="openHelp('firefox-help', 'chrome://browser/locale/help/help.rdf');"/>
s/firefox-help/using-download-manager/.
(In reply to comment #67)
> This should be (content/downloadManagerOverlayMac.xul), I guess.

This was done intentionally. We only want to pack one version of the overlay, so
we pack downloadManagerOverlayMac as downloadManagerOverlay on Mac.
downloadManagerOverlay then overlays the DM regardless of platform.

> s/firefox-help/using-download-manager/.

Right, that makes sense.
Attached patch Use DM specific help (obsolete) — Splinter Review
Attachment #184235 - Attachment is obsolete: true
Attachment #184271 - Flags: review?(mconnor)
Attached patch Correct patch (obsolete) — Splinter Review
Sorry for the spam.
Attachment #184271 - Attachment is obsolete: true
Attachment #184272 - Flags: review?(mconnor)
> > This should be (content/downloadManagerOverlayMac.xul), I guess.
> 
> This was done intentionally. We only want to pack one version of the overlay, so
> we pack downloadManagerOverlayMac as downloadManagerOverlay on Mac.
> downloadManagerOverlay then overlays the DM regardless of platform.
Ah. But
  * content/browser/downloadManagerOverlayMac.xul
  (content/downloadManagerOverlay.xul)
means to pack DMOverlayMac.xul, using the file DMOverlay.xul. What you want is
the other way round. See
http://lxr.mozilla.org/seamonkey/source/browser/locales/jar.mn#50 (help.rdf) for
an example.

I'd rather pack it as DMOverlay.xul, on Mac only, and add an Mac-only "%
overlay" point to jar.mn. So you can use the real names, which is less
confusing, and still pack only one overlay regardless of platform.

I'd also add a comment to DMOverlay.xul saying "on Mac we're using
DMOverlayMac.xul instead".
Attached patch Address Steffen's comments (obsolete) — Splinter Review
Oops, thanks for catching that Steffen.
Attachment #184272 - Attachment is obsolete: true
Whiteboard: [patch-r?] trunk solution: see comment 30 / see bug 21296 for related issue → trunk solution: see comment 30 / see bug 21296 for related issue
Flags: blocking1.8b4?
Flags: blocking1.8b4?
now that this really works on Mac and other platforms can just hit the desktop
shortcut to get a new window, I'm not going to block on this.  Still going to
see about getting the patch landed.
Flags: blocking1.8b4?
Flags: blocking1.8b4-
Comment on attachment 184283 [details] [diff] [review]
Address Steffen's comments

Gavin, I guess you should request review if this patch still applies.
*** Bug 308508 has been marked as a duplicate of this bug. ***
Priority: P2 → P4
Target Milestone: Firefox1.5 → Future
*** Bug 333330 has been marked as a duplicate of this bug. ***
I won't be working on this in the near future. I think the latest patch still works, but IIRC Asaf had a few issues with it.
Assignee: gavin.sharp → nobody
Status: ASSIGNED → NEW
Keywords: helpwanted
Priority: P4 → --
QA Contact: aebrahim-bmo-507 → download.manager
Target Milestone: Future → ---
*** Bug 267996 has been marked as a duplicate of this bug. ***
*** Bug 349941 has been marked as a duplicate of this bug. ***
No longer blocks: 427421
Depends on: 427421
I can't believe this simple bug hasn't been fixed in four years. It's really unconvenient having to close the download window before being able to reopen a browser window instead of just hitting Ctrl+N. This is using FF 3.0 on Windows. On Mac it is working fine.
Product: Firefox → Toolkit
I just noticed this problem on Seamonkey 2.0a3 on Mac OS X.  I can't believe this bug has been around for so long.

One work-around, at least on the Mac, is to select "About Seamonkey" from the Seamonkey menu.  This will open a new browser window.  Re-launching Seamonkey from the Dock or the Finder does not work.
This builds on Gavins 4 year old patch, but also fixes the sidebar behavior:

If there's another browser window around, clone the sidebar from that window (so that there's no difference between pressing Ctrl+N in the download manager or the browser window).

If you've closed the last browser window and press Ctrl+N in the download manager, it uses the sidebar settings persisted from the last browser window.


In browser.js, I refactored a bunch of code into cloneSidebar() because I need it twice.

I copied downloadManagerOverlay.xul to downloadManagerMacOverlay.xul, which is used for Mac only, and created a new downloadManagerOverlay.xul for non-Mac, based on the original file.

I also hooked up the F1 key for Help, but the help topic "downloads-window" needs a redirect to http://support.mozilla.com/en-US/kb/Downloads+window?style_mode=inproduct&s=downloads+window on the sumo side.
Assignee: nobody → steffen.wilberg
Attachment #184283 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #396579 - Flags: review?(dao)
Severity: minor → normal
Keywords: helpwanted
Whiteboard: trunk solution: see comment 30 / see bug 21296 for related issue
(In reply to comment #85)
> I just noticed this problem on Seamonkey 2.0a3 on Mac OS X.  I can't believe
> this bug has been around for so long.
Per comment 30, we're fixing this bug using an app-specific overlay.
Other apps will need to do the same, in separate bugs.

This bug is for Firefox on Windows and Linux. Cmd+N does already work for Firefox on Mac, see comment 73.
Component: Download Manager → Keyboard Navigation
Product: Toolkit → Firefox
QA Contact: download.manager → keyboard.navigation
Attachment #396579 - Flags: review?(dao) → review-
Comment on attachment 396579 [details] [diff] [review]
also fixes sidebar behavior

This conflicts with bug 354894, which made us treat closing the last browser window like quitting even if the download manager is open. Restarting the application, not opening a blank window, is the next logical step after quitting.
(In reply to comment #88)
I don't think so.

If I understand correctly, Bug 354894 saves the session when you close the last non-browser window even if the process doesn't exit because there's e.g. the download manager open. When you launch Firefox from the start menu, a second process gets created, which notices the original one, makes that process open a new window, and terminates itself (you can watch this in the process tab of the task manager). The original process proceeds to restore the session.
The original process doesn't quit and the app is not restarted, it just opens a new browser window, and thanks to bug 354894, it restores the session.

Now with the patch in this bug, instead of launching Firefox from the start menu you can press Ctrl+N from the download manager to open a new browser window. If there's no browser window, the new browser will have the session restored.
If there *is* another browser window around, it will open a new window, just the same as if you press Ctrl+N from the browser itself.
> If there *is* another browser window around, it will open a new window,
... and load the home page ...
> just the same as if you press Ctrl+N from the browser itself.
Restoring a session on Ctrl+N doesn't make sense.
So if you have closed every browser window, but the download manager is still open, and you start Firefox from the start menu, it restores the session (bug 354894). But when you press Ctrl+N in the download manager instead, it should not restore the session and just open the home page?

Wouldn't that be a regression of bug 354894? If I've set the pref to show my windows and tabs from last time, what's the difference between those two use cases?

In comment 88, you said "Restarting the application, not opening a blank window, is the next logical step after quitting."
That means restoring the session in either case, doesn't it?
Keywords: uiwanted
(In reply to comment #92)
> Wouldn't that be a regression of bug 354894?

Yes, it would. That's why I said this conflicts with bug 354894.

> If I've set the pref to show my
> windows and tabs from last time, what's the difference between those two use
> cases?
> 
> In comment 88, you said "Restarting the application, not opening a blank
> window, is the next logical step after quitting."
> That means restoring the session in either case, doesn't it?

Right, but Ctrl+N doesn't mean "launch application".
(In reply to comment #89)
> (In reply to comment #88)
> I don't think so.
> 
> If I understand correctly, Bug 354894 saves the session when you close the last
> non-browser window even if the process doesn't exit because there's e.g. the
> download manager open. When you launch Firefox from the start menu, a second
> process gets created, which notices the original one, makes that process open a
> new window, and terminates itself (you can watch this in the process tab of the
> task manager). The original process proceeds to restore the session.
> The original process doesn't quit and the app is not restarted, it just opens a
> new browser window, and thanks to bug 354894, it restores the session.
> 

Yep.

> Now with the patch in this bug, instead of launching Firefox from the start
> menu you can press Ctrl+N from the download manager to open a new browser
> window. If there's no browser window, the new browser will have the session
> restored.
> If there *is* another browser window around, it will open a new window, just
> the same as if you press Ctrl+N from the browser itself.

This makes sense and is exactly what users will expect and told us (DownThemAll!).

(In reply to comment #93)
> (In reply to comment #92)
> > [...]
> > In comment 88, you said "Restarting the application, not opening a blank
> > window, is the next logical step after quitting."
> > That means restoring the session in either case, doesn't it?
> 
> Right, but Ctrl+N doesn't mean "launch application".

It does actually.
From the user perspective Firefox is an application and Download Manager is another one. If they close the last Firefox window then Firefox is gone to them. Ctrl+N then means "launch Firefox again". Hence restoring the session is correct.

From my personal perspective as a user and from the constant stream of feedback we received with dTa the right course of action is to actually restore the session if there is no browser window around.
(In reply to comment #94)
> > Right, but Ctrl+N doesn't mean "launch application".
> 
> It does actually.
> From the user perspective Firefox is an application and Download Manager is
> another one. If they close the last Firefox window then Firefox is gone to
> them. Ctrl+N then means "launch Firefox again". Hence restoring the session is
> correct.

Ctrl+N is a command within an active session to open a new/fresh/blank window. As you point out correctly, Firefox is considered closed if the last browser window was closed, so the traditional context for Ctrl+N is gone. What that command would mean in that case is currently undefined.
(In reply to comment #95)
> Ctrl+N is a command within an active session to open a new/fresh/blank window.
> As you point out correctly, Firefox is considered closed if the last browser
> window was closed, so the traditional context for Ctrl+N is gone. What that
> command would mean in that case is currently undefined.

The Firefox icon I have in my quick launch bar does exactly the same in an active session.
But when there is no active session then a new browser window will be opened and the session, if any, will be restored.

As I tried to point out users have a pretty clear idea of what Ctrl+N should mean then. And that is "Start Firefox for me!", and not "gimme some blank window and make me think I just lost my session data". Et voilà, users just defined the meaning ;)

To me there are two possible ways to proceed:
 * Don't handle Ctrl+N at all (except for Mac)

 * Open a new browser window and restore the session.
   I'd opt for this one actually, as this is what users would expect telling from the feedback I read and also is what I as a user would think should happen.

Opening a blank window instead of having the session restored will only create the perception of data loss as it did in bug #354894.
Being on this bug since... forever... it's sort of sad to see that it's still not fixed.

Having the download manager running, i and any other user i talked to, expect firefox "to still be there somewhere" and Ctrl+N should open a window with the old session. The download manager is not a separate application from a user's point of view, it's a child of it, since the user opens it through firefox. There's even a menu for it: Tools/Downloads

To make it short: the user does not care if from programmers point of view, the downloads window and firefox window are two separate applications.
Claims about "what users think" are suspect, especially when two diametrically opposed viewpoints are presented as such within three bugzilla comments of each other.
(In reply to comment #91)
> Restoring a session on Ctrl+N doesn't make sense.

Discarding a session after the user has explicitly told Firefox to remember it doesn't make sense. Considering that this shortcut won't even be exposed in the UI and would thus by most users only be hit by accident, dataloss should be prevented as far as possible.

Also, introducing code for such a well hidden feature as Ctrl+N in the Downloads manager just to work around the current (tolerable) behavior seems disproportional.
(In reply to comment #99)
> > Restoring a session on Ctrl+N doesn't make sense.
> 
> Discarding a session after the user has explicitly told Firefox to remember it
> doesn't make sense.

I'm not saying that either of these options make sense.
See also bug 510299; opened for the Win 7 taskbar integration case of this.
Blocks: 438064
Will be fixed by Bug 564934 ?
(In reply to Siddhartha Dugar (sdrocking) from comment #104)
> Will be fixed by Bug 564934 ?

Yes.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago12 years ago
Keywords: uiwanted
Resolution: --- → WONTFIX
How many bugs from 2004 are still around?  Do I win a Mozilla t-shirt or something?
You need to log in before you can comment on or make changes to this bug.