All users were logged out of Bugzilla on October 13th, 2018
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:18.104.22.168) Gecko/20090729 Firefox/3.5.2 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:22.214.171.124) Gecko/20090729 Firefox/3.5.2 In Windows 7, you can "pin" shortcuts (and other things) to the taskbar. This replaces the "Quick Launch toolbar" of previous releases. A pinned shortcut will act in two ways, depending on whether the program is currently running (has a window open): - If no instance is active (no window present), the application will be launched. - If a window is present, it will be brought into the foreground. This is annoying if the only Firefox window open is the Downloads window (or possibly other non-modal windows). In that case, it is not possible to use the button to open another browser window (except by selecting the appropriate entry from the "jumplist" opened by right-clicking the button). I would like to see an improvement to this situation, though I must admit that I cannot think of any that would be acceptable regarding usability and POLA. What might work is closing the Downloads window together with the last browser window if no download is currently active. Reproducible: Always Steps to Reproduce: 1. Pin the Firefox shortcut to the taskbar 2. Use the resulting button to open a browser window. 3. Initiate a download. 4. Close the browser window. 5. Attempt to repeat step 2. Actual Results: The Downloads window is toggled between minimized and normal state. Expected Results: A new browser window should open.
Hey Jim, I suspect this is a dupe of an existing bugs... do you know which one?
There are probably other bugs related to the fact that certain windows (bookmarks, downloads, etc..) don't close down when the last browser window closes. (Really tough to find in bugzilla though.) Maybe we can turn this one into a generic, "certain secondary windows should close when the last browser window closes on win7" bug?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Let's put it in general since shell integration doesn't deal with the windows... this could go under command line or some other component though
Component: Shell Integration → General
QA Contact: shell.integration → general
Hmm. It turns out there is a way to make Windows 7 do what I wanted here: Clicking the button with Shift held down will open a new browser window. I'll leave it to others to decide if the bug should be closed, or if you want to pursue it further.
Yes, shift clicking will create a new firefox process (when then causes the old one to make a new window). I don't think there is a way to determine the users intentions (raising the download window vs opening a new browser window) via a left click.
Somewhat related is bug 240696, which is about making Ctrl+N in the download manager open a new browser window. That bug is stalled on the question whether the session should be restored or not, if the user has set the pref to do so on startup.
Created attachment 405020 [details] The way MS solved this issue with Live Messenger. Some additional info from bug 520900: Proposed behavior (see attachment) when you click the icon and only a download window is open: - show a icon tile to open a new window (containing firefox icon) - show the window tile for the download manager (containing scaled down window of download manager) Workaround 1) Close the download manager and click the firefox icon on the taskbar again 2) Or, right-click the taskbar icon and select "Mozilla Firefox". 3) Shift-click / Middle-click on the firefox icon on the taskbar
(In reply to comment #2) > There are probably other bugs related to the fact that certain windows > (bookmarks, downloads, etc..) don't close down when the last browser window > closes. Rob's bug 544356 just landed for the dm window.
If the user has the jumplist menu enabled in Windows 7, the task _open new window_ already works with only just the Download manager open.
I don't have the bug on hand, but we are also working on converting all these crazy secondary windows into tabs. I think the target release is 4.0.
(In reply to Jim Mathies [:jimm] from comment #11) > I don't have the bug on hand, but we are also working on converting all > these crazy secondary windows into tabs. Should this be closed now, or should it be changed so that it's about any secondary window? * Bug 747422 — the downloads window was replaced with the downloads panel in Firefox 20. * Bug 928349 — the browser.download.useToolkitUI preference to re-enable the window was removed in Firefox 26. * Bug 697359 — for the Library window. (In reply to Jim Mathies [:jimm] from comment #2) > There are probably other bugs related to the fact that certain windows > (bookmarks, downloads, etc..) don't close down when the last browser window > closes. (Really tough to find in bugzilla though.) This was all I could turn up: * Bug 501832.
I think the bug is still valid, the basic str are still there: 1) open firefox 2) open download manager window 3) close browser window 4) click on taskbar button result: download manager window takes foreground expected: new browser window opens
I guess this bug also applies to other products, such as Thunderbird, SeaMonkey.
Component: General → Widget: Win32
Keywords: polish, uiwanted
OS: Windows 7 → Windows
Product: Firefox → Core
Version: unspecified → Trunk
Alternative fix: close downloads window when the last firefox window closes.
Priority: -- → P2
You need to log in before you can comment on or make changes to this bug.