Keyword searches intermittently don't work, end up doing a Google search
Categories
(Firefox :: Address Bar, defect, P2)
Tracking
()
People
(Reporter: mstange, Unassigned)
Details
(Keywords: regression, regressionwindow-wanted)
This is a recent regression; I've only seen this in today's Nightly.
Steps to reproduce:
- Have a Bugzilla bookmark with the search keyword "b".
- Copy a bug number to the clipboard, e.g. 1235467. Then, do the following in very quick succession:
- Open a new tab with Cmd+T.
- Press "b", space, Cmd+V, Enter.
Expected results:
The new tab should execute the keyword search, e.g. navigate to https://bugzilla.mozilla.org/show_bug.cgi?id=1235467.
Actual results:
Sometimes, the new tab initiates a Google search for the string "b 1234567" instead.
This has happened to me about five times today.
|
||
Comment 1•5 years ago
•
|
||
It sounds like the UnifiedComplete provider is taking too long to return the Places keyword heuristic result, so we fall back to the fallback heuristic provider, which ends up returning the search heuristic result. That might indicate that accessing the Places database was particularly slow for some reason, but there's no reason that would only happen recently or with the latest Nightly.
I looked through the past several days of urlbar commits and there's nothing that would obviously affect this.
We may need to get you a one-off build with some extra logging to find out what's going on exactly. Of course if you have time to get a regression range, that would help obviously.
Edit: Also, I wasn't able to reproduce this. I actually have the same bookmark keyword and haven't seen this bug, but I notice my usual Nightly is a little out of date. I'll update and see if it happens to me too.
|
||
Updated•5 years ago
|
|
||
Comment 2•5 years ago
|
||
(In reply to Drew Willcoxon :adw from comment #1)
It sounds like the UnifiedComplete provider is taking too long to return the Places keyword heuristic result, so we fall back to the fallback heuristic provider, which ends up returning the search heuristic result. That might indicate that accessing the Places database was particularly slow for some reason, but there's no reason that would only happen recently or with the latest Nightly.
It's strange, we use PlacesUtils.keywords.fetch(keyword), and the keywords object keeps a memory cache since we expect users have only a few keywords. We should fix bug 1662172 to make things nicer from the concurrency point of view...
But still, I don't think a slow database access may cause this.
The last time this happened, Sync was removing keywords from bookmarks.... Though at that point it would not be intermittent...
|
|
||
Comment 3•5 years ago
|
||
Ah, true.
|
Reporter | |
Comment 4•5 years ago
|
||
I just realized that I was doing something different yesterday - I was running with DMD enabled, so everything was a bit slower.
So this is probably not a regression, but a race that's exposed by different performance characteristics.
|
|
||
Comment 5•5 years ago
|
||
What Drew said applies in that case, if everything is very slow it's likely the urlbar will give up waiting results and just execute the fallback, that in this case is "search for the string". We should probably examine whether we started waiting for too many things, or if the timeout needs a bump. Maybe with slow hardware.
|
|
||
Comment 6•5 years ago
|
||
I'm suspecting https://searchfox.org/mozilla-central/rev/d866b96d74ec2a63f09ee418f048d23f4fd379a2/browser/components/urlbar/UrlbarEventBufferer.jsm#26, I bumped it up to 300ms recently, may still not be enough.
|
|
||
Comment 7•5 years ago
|
||
It's a hard thing to reason about. Maybe some telemetry would help? We could capture the cases where the "expected" heuristic arrives but only after some other heuristic. What's expected may not be clear in every case of course, but in this case, the UX we want is for the heuristic to be the Places keyword, not the fallback search result. That might give us a sense of how good/bad our timeout(s) are.
|
|
||
Comment 8•2 years ago
|
||
I think bug 1816572 has improved the situation here... there's still a timeout though after sometime that we don't get results, and in that case we may still execute a search, but it should be rarer.
Description
•