1002486 - Clicking the toolbar download button drops browser window focus

Status: RESOLVED INVALID

(Firefox :: Downloads Panel, defect)

Description

[Aaron Train [:aaronmt]]

Relatively minor bug but I just noticed this on a fresh installation of Firefox 29 (OS X 10.9.2). On click of the download button, the browser window loses focus. You can test this on about:home, e.g, focus the search box and then tap the default toolbar download button. Focus is removed. Clicking the browser menu does not drop focus. Clicking the default bookmarks button does not drop focus.

--
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Firefox/29.0

Comment 1

[:Gijs (he/him)]

This happens for the bookmarks dropdown too, on my copy of 29... Am I missing something?

Comment 2

[Aaron Train [:aaronmt]]

Doesn't for me. The window retains focus. For me, only on invoking the download panel, the browser window drops focus. You can tell on about:home when the Search button changes colour.

Comment 3

[:Gijs (he/him)]

(In reply to Aaron Train [:aaronmt] from comment #2)
> Doesn't for me. The window retains focus. For me, only on invoking the
> download panel, the browser window drops focus. You can tell on about:home
> when the Search button changes colour.

Hrm, I see. The cursor disappears, though, and keypresses no longer go to the search box. If using the search box in the browser chrome, the effect is the same when comparing the two buttons. Oddly, the main panel from the "hamburger button" works the same as the bookmarks dropdown.

This isn't a regression with 29, as far as I can tell. I suspect this is because the panel has level="top", which was because it would overlap with the taskbar on Windows without that attribute. Fortunately, that was a bug we fixed for 29 (for all panels). See 

http://mxr.mozilla.org/mozilla-central/source/browser/components/downloads/content/downloadsOverlay.xul#39

and bug 627974.

So I think we can just fix this by removing level="top" and testing carefully.

Comment 4

[:Gijs (he/him)]

(In reply to :Gijs Kruitbosch from comment #3)
> Oddly, the main panel from the
> "hamburger button" works the same as the bookmarks dropdown.
> 
> This isn't a regression with 29, as far as I can tell. I suspect this is
> because the panel has level="top", which was because it would overlap with
> the taskbar on Windows without that attribute. Fortunately, that was a bug
> we fixed for 29 (for all panels). See 
> 
> http://mxr.mozilla.org/mozilla-central/source/browser/components/downloads/
> content/downloadsOverlay.xul#39
> 
> and bug 627974.
> 
> So I think we can just fix this by removing level="top" and testing
> carefully.

That doesn't seem to fix this. Nor does adding the noautofocus attribute and setting it to true. Neil, can you help explain why the downloads button is different? (Mike / Paolo, also CC'ing you because perhaps you know, and this seems relevant to your interests... :-) )

Comment 5

[Neil Deakin]

I'm pretty sure the downloads panel focuses its list intentionally so you can navigate the download items in it with the keyboard. So this bug isn't valid.

Comment 6

[:Gijs (he/him)]

(In reply to Neil Deakin from comment #5)
> I'm pretty sure the downloads panel focuses its list intentionally so you
> can navigate the download items in it with the keyboard. So this bug isn't
> valid.

Hrm. That doesn't make sense if the list is empty, though... Mike, can you clarify if we can fix something here or this is completely invalid?

Comment 7

[Marco Bonardo [:mak]]

yep, we allow to navigate the panel with the keyboard, Show all Downloads is also among the stuff you can browse with the keyboard. Whether it should ot not happen on an empty panel is likely an UX decision. Though, it would be a little bit weird to male the focus behavior unpredictable by changing it based on contents.

Comment 8

[:Paolo Amadini]

(In reply to Marco Bonardo [:mak] from comment #7)
> Though, it would be a
> little bit weird to male the focus behavior unpredictable by changing it
> based on contents.

I also think a consistent focus behavior is to be preferred.

Comment 9

[:Gijs (he/him)]

Sounds like this isn't really fixable without breaking functionality we want.