Closed Bug 1652217 Opened 4 years ago Closed 4 years ago

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)

80 Branch
defect

Tracking

()

RESOLVED DUPLICATE of bug 1652024

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.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Address Bar

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.

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.

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.

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE

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.

Yeah, it's related to timing, which can depend on the DB size and also your WPM, as you've found.

You need to log in before you can comment on or make changes to this bug.