1327070 - Searchbar shows suggestions even if I no longer interact with it (when it gains focus)

Status: NEW

(Firefox :: Search, defect, P3)

Description

[arni2033]

>>>   My Info:   Win7_64, Nightly 49, 32bit, ID 20160526082509
STR_1:
1. Type "asdf" in searchbar
2. Press Escape key to hide suggestions
3. Press Ctrl+D to bookmark current page
4.A) Press Enter (while bookmarks panel is still visible) to create bookmark
4.B) Or wait 5 seconds until bookmarks panel hides (this is intentional regression from bug 1219794)


STR_2:
1. Type "asdf" in searchbar
2. Press Escape key to hide suggestions
3. Click downloads toolbarbutton in toolbar
4. Click downloads toolbarbutton or press Escape key to hide downloads panel opened in Step 3


STR_3:
1. Enable Ctrl+Tab previews in browser, open many tabs to cause overflow in tabs toolbar
2. Type "asdf" in searchbar
3. Press Escape key to hide suggestions
4. Press Ctrl+Tab several times to switch to button "Show all tabs", release Ctrl key to show all tabs


AR:  Search suggestions appear after Step 4 - completely unexpected
ER:  After Step 4 there should be no autocomplete suggestions


@ Florian Quèze
Please decide asap whether you can remove this terrible regression ("show suggestion on focus") from
searchbar. If yes, it would make it way easier for Neil & Co to fix bug 1219510 (unless they decide to
fix it in general case, for all possible add-ons that show popups on focus... I'm not aware of that).

Comment 1

[arni2033]

Attachment: screenshot 1 - bug 1327070.png

Comment 2

[Florian Quèze [:florian]]

(In reply to arni2033 [Please stop 'improving' Firefox] from comment #0)

> @ Florian Quèze
> Please decide asap whether you can remove this terrible regression ("show
> suggestion on focus") from searchbar.

This was a UX decision, not something I decided.

That said, I think UX really wanted the suggestion to appear when users clicked on the searchbox while it wasn't focused. Not necessarily in all possible cases that cause the searchbox to gain focus.

All the cases you mention in comment 0 are the searchbox gaining focus as a side-effect of another element losing focus. I think we only intend to show suggestions when the searchbox gains focus as the result of the user focusing it. I don't know if there's a way for the code receiving the focus event to know how it was triggered.

Comment 3

[:Gijs (he/him)]

(In reply to Florian Quèze [:florian] [:flo] from comment #2)
> (In reply to arni2033 [Please stop 'improving' Firefox] from comment #0)
> 
> > @ Florian Quèze
> > Please decide asap whether you can remove this terrible regression ("show
> > suggestion on focus") from searchbar.
> 
> This was a UX decision, not something I decided.
> 
> That said, I think UX really wanted the suggestion to appear when users
> clicked on the searchbox while it wasn't focused. Not necessarily in all
> possible cases that cause the searchbox to gain focus.
> 
> All the cases you mention in comment 0 are the searchbox gaining focus as a
> side-effect of another element losing focus. I think we only intend to show
> suggestions when the searchbox gains focus as the result of the user
> focusing it. I don't know if there's a way for the code receiving the focus
> event to know how it was triggered.

Maybe https://dxr.mozilla.org/mozilla-central/source/dom/interfaces/base/nsIFocusManager.idl#78 ? The focus manager clearly knows. If it's not already, perhaps we could expose it on the focus event using a [ChromeOnly] property? It's probably useful in other cases.

Comment 4

[Florian Quèze [:florian]]

Clearing needinfo as I'm no longer focusing on Search.

Comment 5

[Timea Cernea [:tbabos][inactive]]

After running mozzregression I got the following results: 

Got as far as we can go bisecting nightlies...
Last good revision: 17de0f463944 (2014-11-28)
First bad revision: e90536aa55dd (2014-11-29)

Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=17de0f463944&tochange=e90536aa55dd

Comment 6

[:Gijs (he/him)]

(In reply to Timea Babos from comment #5)
> After running mozzregression I got the following results: 
> 
> Got as far as we can go bisecting nightlies...
> Last good revision: 17de0f463944 (2014-11-28)
> First bad revision: e90536aa55dd (2014-11-29)
> 
> Pushlog:
> https://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=17de0f463944&tochange=e90536aa55dd

This includes an e10s enabling. I expect it's always been broken in e10s.

Comment 7

[Liz Henry (:lizzard) (relman/hg->git project)]

Happy to take a patch in nightly; if it seems low risk enough please feel free to request uplift to 65 beta.

Comment 8

[Clara Guerrero ( Need Info Brindusa Tot Please)]

Hi,

I've tested this using Firefox Nightly version 75.0a1 (2020-02-12) (64-bit), Beta 74.0b2 (64-bit) and Release 73.0 (64-bit) for windows 10 pro and I’m also able to reproduce the issue (only the STR_3 case). Based on this I will mark each respective flag as affected.

Best,
Clara