1219510 - Panels return focus to a wrong element when they close (basically steal focus)

Status: NEW

(Toolkit :: UI Widgets, defect)

Description

[arni2033]

Attachment: screenshot (just a simple example) No suggestions should appear.png

STR:   (Win7_64, Nightly 44, 32bit, ID 20151027030239, new profile)
1. Click on searchbar's input, type "zxcv"
2. Click downloads button on toolbar
3. Move mouse pointer over any button which isn't overlapped by downloads panel (actually that also
   works with locationbar's input, free space before & after tabs [but not tabs itself], findbar,
   and not-focusable xul in devtools)
4. Press left mouse button (or right as well), but don't release it for several seconds to see the result

Result: Right after Step 4 downloads panel gives focus back to searchbar and it displays the suggestions

Expectations: No suggestions should appear.

Searchbar's behavior on showing suggestions is too aggressive - it was noted in some issues on bugzilla. I personally used to press Escape when urlbar is focused, then double-Tab to the content. But since new searchbar was introduced, those steps no longer work - it shows suggestions. My_personal_opinion is that
> searchbar shouldn't show suggestions on focus at_all, just like in old versions
Note: Actually it's possible to change downloads panel's behavior to get rid of this bug,
      but there's several bugs which could be solved with solution I suggested.

Comment 1

[arni2033]

Regression from bug 610545 (presumably). Regression range:
> https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8883360b1edb&tochange=5811efc11011

Comment 2

[:Gijs (he/him)]

Why move this bug to general if you think it's related to the search bar?

Comment 3

[arni2033]

(In reply to :Gijs Kruitbosch from comment #2)
> Why move this bug to general if you think it's related to the search bar?
The new searchbar has very offending behavior that made this bug noticeable for me.
But then it became clear that downloads panel just gives focus back to the same element when it collapses. Even if I click on another focusable element.
I was hoping that somebody will correct Component and Summary, because I have no idea.

Comment 4

[arni2033]

> downloads panel just gives focus back to the same element
Hm, not exactly. But if I take 3 <input>s:   urlbar, searchbar and <input> on the page, and try to 
{click first_input -> click downloads button -> click second_input},  then downloads panel will always give focus to the first_input.
If I try the same with 2 <input>s on a page, then downloads panel doesn't interfere.

Comment 5

[:Gijs (he/him)]

(In reply to arni2033 from comment #4)
> > downloads panel just gives focus back to the same element
> Hm, not exactly. But if I take 3 <input>s:   urlbar, searchbar and <input>
> on the page, and try to 
> {click first_input -> click downloads button -> click second_input},  then
> downloads panel will always give focus to the first_input.
> If I try the same with 2 <input>s on a page, then downloads panel doesn't
> interfere.

Even in non-e10s?

Comment 6

[arni2033]

Yea, there's no difference between single-process and multi-process modes

Comment 7

[:Gijs (he/him)]

Neil, do you know why focus behaves in this way?

Comment 8

[Neil Deakin]

The downloads panel moves focus to itself when opened so that the keyboard can be used to navigate it because its using a richlistbox rather than a menu. The focus is then restored when the popup is hidden, which happens after the closing animation is complete. This causes the search dropdown to appear as it opens on focus.

Meanwhile, before the animation has completed, the popup for the other button opens.

Comment 9

[:Gijs (he/him)]

(In reply to Neil Deakin from comment #8)
> The downloads panel moves focus to itself when opened so that the keyboard
> can be used to navigate it because its using a richlistbox rather than a
> menu. The focus is then restored when the popup is hidden, which happens
> after the closing animation is complete. This causes the search dropdown to
> appear as it opens on focus.
> 
> Meanwhile, before the animation has completed, the popup for the other
> button opens.

Can we avoid doing the focus restoration bit if focus has moved already, as it has in the STR from comment #0? Is the downloads panel manually doing this or is there some kind of interaction with the core XUL code for this?

Comment 10

[Neil Deakin]

> Can we avoid doing the focus restoration bit if focus has moved already, as
> it has in the STR from comment #0? Is the downloads panel manually doing
> this or is there some kind of interaction with the core XUL code for this?

The focus doesn't move again; it stays in the searchbar.

You can use norestorefocus="true" to avoid restoring the focus, but then it would be in the downloads panel which you don't want.

Comment 11

[:Gijs (he/him)]

(In reply to Neil Deakin from comment #10)
> > Can we avoid doing the focus restoration bit if focus has moved already, as
> > it has in the STR from comment #0? Is the downloads panel manually doing
> > this or is there some kind of interaction with the core XUL code for this?
> 
> The focus doesn't move again; it stays in the searchbar.

If I do:

1. focus search bar
2. type stuff
3. click downloads button
4. click location bar

then the location bar is initially focused (I can see a flash of the text in it being selected on my windows machine), after which the search bar is focused.

> You can use norestorefocus="true" to avoid restoring the focus, but then it
> would be in the downloads panel which you don't want.

No, I want the focus to go to where it was before it got "restored", because that's where I put it...

Comment 12

[Neil Deakin]

Attachment: restoreonlyifsame

OK, for the locationbar specific case this could be fixed. But it wouldn't fix the case for clicking other buttons.