Urlbar search query does not update immediately upon typing anymore, you have to pause for a second before hitting enter
Categories
(Firefox :: Address Bar, defect)
Tracking
()
People
(Reporter: aminomancer, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:80.0) Gecko/20100101 Firefox/80.0
Steps to reproduce:
- type a regular query like "how do you tie your shoes" into the urlbar, at least like 80 words per minute
Actual results:
- even though the characters you're typing appear in the urlbar instantly, they don't appear in the first urlbarView-row (or any of the other urlbar results) until after a short pause. and the first result is the one you end up searching if you hit enter. it wasn't like this a week or 2 ago. if you hit enter immediately after you finish typing, instead of searching "how do you tie your shoes" you'll search something like "how" or you'll end up selecting a bookmark, history item, or open tab that had "how" in the title, because this is so slow now.
Expected results:
- the urlbar results should update quickly like they did before. if that's no longer possible because something else is a higher priority to somebody, then the first urlbar result should not use the same type of predictive suggestion system or whatever. make some kind of boolean pref that will make it so when you hit enter (or click the "go" arrow in the urlbar) while typing in the urlbar, it will just resolve the user input, verbatim, as the search query. either as a domain or a search term. none of the settings in about:preferences seem to make a difference in the speed at which the results resolve. i tried toggling some prefs under browser.urlbar too, to no effect.
Comment 1•4 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
Reporter | ||
Comment 2•4 years ago
|
||
Oh FYI the default search engine I'm using is Google, which is the default for firefox. I have others installed through search.json.mozlz4 but just for the search one-offs. I also tested this with a brand new "blank" profile and it was exactly the same.
Reporter | ||
Comment 3•4 years ago
|
||
I can provide a video of this if someone can't reproduce it for some reason. I probably won't do a regression unless nobody has any ideas because it always messes up my main profile's sessionstore, and restoring it from a backup causes my tabs and some extension storage to get wiped. I do know I've been experiencing it since yesterday, so 2 different revisions of branch 80. But I updated yesterday for the first time in 2 weeks, so this bug was likely introduced earlier and I just only caught it when I finally updated.
Comment 4•4 years ago
|
||
Thanks for reporting this. This is bug 1652024 so I'll dupe it, but please correct me if I'm misunderstanding. We're working on a fix.
Reporter | ||
Comment 5•4 years ago
|
||
Yeah that sounds exactly like what I'm experiencing but I do not think it has anything to do with the size of my places DB, because I get exactly the same thing at exactly the same frequency on a completely brand-new profile that's not logged in and has no bookmarks, history, etc.
Comment 6•4 years ago
|
||
Yeah, it's related to timing, which can depend on the DB size and also your WPM, as you've found.
Description
•