1303462 - Trying to select an autocomplete entry sometimes takes me to about:preferences#search instead

Status: RESOLVED FIXED

(Firefox :: Address Bar, defect, P2)

Description

[Josh Matthews [:jdm]]

STR:
1. highlight the location bar via the keyboard
2. type something that will bring up autocomplete results besides the search option
3. press `down` in order to skip the search option and go to the first history entry in the list
4. press `enter`

Expected:
The history entry is navigated to.

Actual:
Intermittently, the tab ends up navigating to about:preferences#search instead.

I've caught this behaviour a few times before I actually press enter - if the dropdown is given a chance to update, all of the other history entries disappear after `down` is pressed, and only the search option is present. Pressing enter at this point goes to about:preferences#search, despite having the appearance that it should initiate a web search (despite the fact that I pressed down when there were history entries and nothing should have changed in the location bar contents...)

Comment 1

[Josh Matthews [:jdm]]

I've been able to reproduce this more intentionally when I'm changing the location bar's contents while a page is loading - sometimes the page finishes loading and updates the bar's contents while I'm interacting with the dropdown, and I end up with the current page's URL with my location bar text appended to it, at which point the dropdown redraws and shows only the single search option. Pressing enter at that point takes me to about:preferences#search.

Comment 2

[Drew Willcoxon :adw]

Hmm, there was a bug that we fixed, bug 1293300, where if your mouse cursor simply happened to be over a search tile or the settings button when the popup opened, and you pressed return, you'd trigger a search or open the settings page.  Not sure what could be causing this now.

Thanks for filing.

Comment 3

[Marco Bonardo [:mak]]

down is not buffered, only enter is, but only as far as the first entry arrives.
since down will also navigate to one-off buttons, I can imagine that in certain situations doing quite fast typing + down + enter may end up selecting whatever is after the first result, that in some cases could be the search settings button.
Though that would require other search buttons to not be there... Do we repopulate one-off every time the popup opens?

A long term solution, is to buffer also DOWN and TAB along with enter, and manage them at the most approriate time. it's scary though.

Comment 4

[Drew Willcoxon :adw]

(In reply to Marco Bonardo [::mak] from comment #3)
> Though that would require other search buttons to not be there... Do we
> repopulate one-off every time the popup opens?

Yes, so your theory may be right.  Maybe we could simply disable the one-offs for a brief period.  Just thinking out loud, this deserves much more thought.

Comment 5

[Marco Bonardo [:mak]]

The only long term fix is to buffer down/up and tab.
Sure we could workaround by hiding the one-off, but it would still not do what Josh expects.
I wonder if we could have something that pauses and caches all events to a widget, and then replays them on request.

That said, why do we rebuild all the one-off at every opening, sounds like very expensive and pointless, engines don't change that often.

Comment 6

[Marco Bonardo [:mak]]

btw, bug 1283329 could have helped a little bit, I cannot reproduce this in current Nightly, could be I'm not fast enough or my PC is too fast.

Comment 8

[Drew Willcoxon :adw]

(In reply to Marco Bonardo [::mak] from comment #5)
> That said, why do we rebuild all the one-off at every opening, sounds like
> very expensive and pointless, engines don't change that often.

That behavior was present before the refactoring for the urlbar one-offs, so Florian probably has a better idea of why.  Maybe just simplicity?  We could see if we can avoid it.

Comment 9

[Marco Bonardo [:mak]]

florian, can you try to answer the question in comment 8 please?

Comment 10

[Florian Quèze [:florian]]

(In reply to Drew Willcoxon :adw from comment #8)
> (In reply to Marco Bonardo [::mak] from comment #5)
> > That said, why do we rebuild all the one-off at every opening, sounds like
> > very expensive and pointless, engines don't change that often.
> 
> That behavior was present before the refactoring for the urlbar one-offs, so
> Florian probably has a better idea of why.  Maybe just simplicity?  We could
> see if we can avoid it.

Yes, it was for simplicity. We developed this code under extreme time pressure, and not having to figure out which cases should invalidate the list of one-offs saved us engineering time. It never appeared to cause performance issues, so we never optimized it.

Comment 11

[Marco Bonardo [:mak]]

Ok, for the search bar it may not be a problem, but the urlbar popup is opened/closed a lot, so it may actually be worth to cache one off buttons and have an invalidate strategy.

Comment 12

[Gerry Chang [:gchang]]

Hi Marco,
Do you have any updates for this one since this also affects bug 1303781?

Comment 13

[Marco Bonardo [:mak]]

unfortunately not, it's in our backlog but nobody is working on it yet.

Comment 14

[Drew Willcoxon :adw]

(In reply to Marco Bonardo [::mak] from comment #3)
> down is not buffered, only enter is [...]
> [...]
> Though that would require other search buttons to not be there... Do we
> repopulate one-off every time the popup opens?

Florian fixed bug 1312999, and bug 1303781 is hopefully close to landing.  With those two bugs fixed, this should be fixed, too.

I'm going to reverse the dependency here on bug 1303781 to reflect that, and add a dependency on bug 1312999.

Comment 15

[Drew Willcoxon :adw]

I'll mark this fixed now that both those bugs have landed.  If you still see problems, please reopen or file new bugs.