1896167 - Keyword-triggered bookmarks (e.g. "bug NNN") is ignored when a query is followed by a consistent (200ms+) jank time

Status: NEW

(Firefox :: Address Bar, defect, P3)

Description

[Daniel Holbert [:dholbert]]

[Unfortunately I don't have reliable STR, but it's happening often enough -- several times per week at least -- that I figured I should file]

Unreliable STR:

1. Create a Bookmark with the following values:

URL: https://bugzilla.mozilla.org/show_bug.cgi?id=%s
Keyword: bug

2. Ctrl+L to focus Address Bar.
3. Type bug and then paste in some bug number, and hit enter

EXPECTED RESULTS: Bugzilla page for bug [number]
ACTUAL RESULTS: Occasionally I end up at a Google Search page for the "bug [number]" text that was in the URLbar, i.e. https://www.google.com/search?client=firefox-b-1-d&q=bug+[number]

Comment 1

[Daniel Holbert [:dholbert]]

This happens for my searchfox keyword-bookmark, too (which I set up with the "sf" keyword) -- occasionally I end up unexpectedly landing on a google search results page for "sf nsblockframe" or whatever, when I meant to end up at https://searchfox.org/mozilla-central/search?q=nsblockframe&path=

Comment 2

[Marco Bonardo [:mak]]

Is this on Nightly?
Is there a timeframe where this started happening more often? Like last week, last month, last N months?
I suppose there's nothing shown in the Browser Console when it happens?
Any urlbar related pref you may have flipped (otherwise feel free to attach an about:support log)
Was the disk/system particularly busy when it happened?

Technically, after Bug 1667639 we'll know if the first token is a keyword, thus it should be easier to avoid the fallback, that afaict should only happen if we take longer than 300ms to return a bookmark keyword result.

Comment 3

[Daniel Holbert [:dholbert]]

(In reply to Marco Bonardo [:mak] from comment #2)

Is this on Nightly?

Yup, Nightly.

Is there a timeframe where this started happening more often? Like last week, last month, last N months?

Possibly started in the last 3 months or so, but I'm not entirely sure. This hasn't been a "forever" bug, but I'm not sure how recently it started.

I suppose there's nothing shown in the Browser Console when it happens?

Not sure, I'll see.

Any urlbar related pref you may have flipped (otherwise feel free to attach an about:support log)

The only one I recall flipping is "show search suggestions ahead of browsing history in address bar results" (which I disabled).

I'll email you my about:support contents in case anything else in there is relevant.

Was the disk/system particularly busy when it happened?

Generally no, though I've got quite a few tabs open, so it's possible there's some load associated with that.

Comment 4

[Marco Bonardo [:mak]]

Daniel was so kind to send me additional debugging information and profiles.

In all the cases the urlbar startQuery method is invoked just before a jank, caused by something else (sometimes it's Sync converting a large uri string into an nsIURI, sometimes it's layout, sometimes it's session restore saving to json). That jank is usually 200+ ms.

Now the urlbar has a 300ms internal timeout when Enter is pressed, to give time to heuristic results to arrive, that is fine most of the times. Though if the timeout happens, it will just serve whatever is available at that time. A long jank is making it easier for the timeout to happen.

We could increase the timeout to 500ms as a stop-gap, though it wouldn't be a long term solution.
We could remove the timeout completely, but then a heuristic provider, under certain conditions, could prevent the urlbar from serving Enter forever. Maybe the providers manager should just race each heuristic provider with a timeout, but the effect wouldn't be much different than this already existing provider.
It would be great if the timeout could somehow keep jank into account, but I doubt that's available in the platform.

One thing we may want for sure, is to measure in telemetry how many times this timeout is effectively hit when there's still heuristic providers pending. Maybe increasing the timer and monitoring that telemetry will be a good first step.

We could also try to optimize the keywords provider, as now we already know from the first token if it's a keyword, it could probably also contain all the necessary info to build the result, then it would return much faster.