264897 - Inconsistent behavior when clicking the Download Manager toolbar button with the Download Manager already open

Status: RESOLVED WONTFIX

(Firefox :: Toolbars and Customization, defect)

Description

[John Stahara]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041013 Firefox/0.10
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041013 Firefox/0.10

When the Download Manager window is open, left-clicking on the Download Manager
toolbar button sends it behind the main window on mouse-down, then raises it
again on mouse-release.  If one wants to hide the window, one can click down on
the button and drag the cursor off of the button before releasing the mouse
button, leaving it behind the main window without bringing it back to the
foreground.  If one simply clicks and releases the button (normal single-click),
the Download Manager window drops behind the main browser window and immediately
returns back to the foreground on mouse-release.

Reproducible: Always
Steps to Reproduce:
1. Place the Download Manager button in the toolbar
2. Open the Download Manager, either with the toolbar button, the hotkey, or via
the Tools menu.
3. Left-click the Download Manager toolbar button, both clicking down and
immediately releasing (without moving the cursor) and clicking down and moving
the cursor away before releasing.
Actual Results:  
When clicking down and immediately releasing without moving the cursor, the open
Download Manager window is sent behind the main browser window and immediately
brought back to the foreground on the release.  When clicking down and moving
the cursor away from the button before releasing, the Download Manager gets sent
behind the main browser window and stays there.

Expected Results:  
Both left-click actions should close the Download Manager window, making the
button a toggle for the window (click once to open, click again to close).

Bug occurs with the default theme.

Comment 1

[Bogdan Butnaru]

(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Gecko/20041013 Firefox/0.10
> Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Gecko/20041013 Firefox/0.10

I get the same behaviour with "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7.5) Gecko/20041109 Firefox/1.0", it's probably XUL-related.

Comment 2

[Hans-Andreas Engel]

Currently, when the "Downloads" toolbar Button clicked and the "Download
Manager" is already open, it will bring the "Download Manager" to the front.

Combined with certain window manager policies of the operating system, this can
lead to the described behavior, namely that (1) when the button is pressed, the
system thinks that the window containing the toolbar is important and brings is
to the front (possibly hiding the download manager) and (2) when the mouse is
released outside the button, this is not registered as click (and nothing
happens); for a valid click the download manager is brought to front again.


I suggest changing the behavior of the "Downloads" Button such that it toggles
the download manager, i.e., it closes the download manager if it is already open.

This would eliminate the disturbing behavior explained in the summary.  Also, it
seems that a similar 'toogle' behavior is already implemented for the "History"
Button; clicking this button a second time (while the history bar is open)
closes the history.  Further, the toolbar of MS Word contains several buttons
with a similar behavior.

Comment 3

[Hans-Andreas Engel]

Attachment: implement 'toggle' behavior for Downloads Button

Comment 4

[Hans-Andreas Engel]

The proposed change also allows a convenient check of the download status: 
Click the "Downloads" Button to see the current downloads, click it again
*without moving the mouse* to hide them.

Comment 5

[Hans-Andreas Engel]

Note that the "Ctrl-J" keyboard shortcut for "Tools > Downloads" works very
similar to the proposed solution.  Namely, if the Download Manager is open and
is the topmost window, pressing Ctrl-J *closes* it.

However, if the Download Manager window is not topmost, Ctrl-J brings it to
front.  This behavior would be difficult to emulate perfectly, because when the
"Downloads" button is clicked, the containing browser window comes to the front
and therefore the Download Manager window never is the topmost.  So to achieve
perfectly equivalent behavior, one  would probably make a decision based on what
was the topmost window just before the mouse-down event.

Comment 6

[kartick]

any chance of this going into 2.0?

Comment 7

[Martijn Wargers (dead)]

The person who has made the patch has to ask review to someone, if he thinks the patch is good enough.

Comment 8

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Comment on attachment 196373 [details] [diff] [review]
implement 'toggle' behavior for Downloads Button

r=me on the functional part of the patch; however; the UI decision needs to come from mconnor and/or beltzner.

Comment 9

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #0)
> Expected Results:  
> Both left-click actions should close the Download Manager window, making the
> button a toggle for the window (click once to open, click again to close).

I see a very likely use case (especially on Mac, but equally on Windows and Linux) where someone starts a download, and then completely covers the DM with their main browser window. Then they want to get to the DM, so they click the button which will *close* the DM, meaning that the user sees absolutely no effect.

I think the better behaviour is the toggle-behaviour used by the keyboard shortcut, which is: Open/Bring to Fore/Close, but as noted in comment 5, this would require a more complicated patch.

Comment 10

[Mike Connor [:mconnor]]

Comment on attachment 196373 [details] [diff] [review]
implement 'toggle' behavior for Downloads Button

So, we looked at this behaviour (and had a much better implementation) in bug  228699, and in the end decided it was confusing behaviour, since you'd have to click twice to get to a background window.

Comment 11

[Mike Connor [:mconnor]]

I'm going to mark this WONTFIX, since the only case where it makes sense to close the window is when its visible and in the foreground, in which case I don't know why anyone's going to click on it instead of the close widget of the dlmgr itself.  The quick toggle behaviour is interesting in the open-look-close case, but functionally, that's clicking on the downloads button, and clicking the browser window again, other than the window closing.  Adding in pseudo-guesswork (since I don't think we can tell if a window is on top of all windows in the OS, at least not accurately cross-platform, and that matters if the window is under a different app, but not on top of the browser) is just a bad idea.  I don't think there's a perf big win by closing/reopening the window, especially with the overhead of building the window each time.

Comment 12

[Adam Guthrie]

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