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.

-> NEW, this is absolutely valid.

*** 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!

It might be easy for a novice to notice this bug. Nominating for 1.0

Not stop ship although may reconsider with a simple patch.

Mark Bokil's change from comment 5 in patch format. Does not include the button.

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.

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.

Allows Ctrl+N from DM, localizable, adds strings for a button if needed in the future.

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.

Addressed comments

Comment on attachment 157497 [details] [diff] [review] Patch v2 (comments addressed) Carrying over r=mconnor per comment 13

*** 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.

Can someone checkin this patch?

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.

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.

Comment on attachment 160061 [details] [diff] [review] Patch v3 (checked into aviary, backed out from trunk) OK, great

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.

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

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 .

Made changes brought up in comment 34.

Oops, forgot to remove what was there before.

Removing fixed-aviary to address comment 34. If attachment 161436 [details] [diff] [review] is checked in this will be fixed.

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.

Comment on attachment 161436 [details] [diff] [review] Patch v4.1 (followup, mac support) Trying Blake for review

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.

*** 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. ***

Comment on attachment 161436 [details] [diff] [review] Patch v4.1 (followup, mac support) Almost zero chance for 1.0. But who knows.

-> Gavin.

Comment on attachment 161436 [details] [diff] [review] Patch v4.1 (followup, mac support) Too late for 1.0

*** Bug 268250 has been marked as a duplicate of this bug. ***

*** Bug 268297 has been marked as a duplicate of this bug. ***

Landing of aviary branch has checked this patch back in, does it need to be reversed out?

(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.

Diff -up8 of previous patch.

Yes, please back this patch out of the trunk, until a real solution can be found.

Backed out again

*** 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.

*** Bug 140582 has been marked as a duplicate of this bug. ***

I assume we want at least the open-help keys as well.

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

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.

Sorry for the spam.

> > 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".

Oops, thanks for catching that Steffen.

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.

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. ***

*** 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.

*** Bug 267996 has been marked as a duplicate of this bug. ***

*** Bug 349941 has been marked as a duplicate of this bug. ***

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.

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.

(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.

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?

(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.

Will be fixed by Bug 564934 ?

(In reply to Siddhartha Dugar (sdrocking) from comment #104) > Will be fixed by Bug 564934 ? Yes.

How many bugs from 2004 are still around? Do I win a Mozilla t-shirt or something?