1744367 - Typing "g" and waiting, then pressing enter takes me to google maps. Typing "g" and pressing enter instantly takes me to google.com

Status: VERIFIED FIXED

(Firefox :: Address Bar, defect, P3)

Description

[talondaniels]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:94.0) Gecko/20100101 Firefox/94.0

Steps to reproduce:

I typed "g" into the address bar and pressed enter.

Actual results:

I typed a "g" into the address bar and did not see google.com get autocompleted. If I press enter after a second or so, it ends up taking me to https://www.google.com/maps. However, if I type "g" into the address bar and then very quickly press enter, it takes me to the expected https://www.google.com/

Expected results:

When I type a "y" into the address bar, it shows a highlighted "youtube.com". When I type a "r" into the address bar, it shows a highlighted "reddit.com". When I type a "n" into the address bar, it shows a highlighted "news.ycombinator.com". All of these are expected as they are websites I have visited before/frequently.

However, something special is happening with "g". When I type just "g", I don't see any domain get highlighted, however pressing enter ends up taking me to an unexpected Google Maps. I would expect that typing "g" should behave the same way as the other letters and show a highlighted "google.com" that takes me to Google upon pressing enter, and doesn't require me to do so nearly instantly.

Video showing the issue: https://www.youtube.com/watch?v=5WyF55yz-8w

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Firefox::Address Bar' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Hani Yacoub, Desktop QA]

Could you please change your default search engine and test again to see if that makes any difference?
Thanks.

Comment 3

[talondaniels]

I tried switching the Default Search Engine to Google, Bing, Wikipedia, and then back to DuckDuckGo but I get the same behavior on each of them. I restarted Firefox after switching each time as well. Although while I was in the settings I also tried unchecking Google in the Search Shortcuts and that seems to have fixed the issue so I suppose this could be closed as that works for me. I also just realized that pressing "a" doesn't show a highlighted "amazon.com" either unless I also uncheck Amazon from the Search Shortcuts. If that doesn't seem like a bug though then feel free to close this.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:adw, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 5

[Drew Willcoxon :adw]

Attachment: bug1744367.png

Thank you for reporting this. It's very strange and definitely not the right behavior.

I've attached screenshots from the video. This is what happens:

1. User types g
2. google.com/ is autofilled and the heuristic result is the expected google.com visit result
3. The autofilled oogle.com part in the input disappears, the visit result disappears, and the first result becomes maps.google.com and it's selected
4. The maps.google.com result disappears. The first result becomes a form history result and the second result is tab-to-search for Google. No result is selected
5. The user presses the Enter key and maps.google.com loads

Another user reported a similar problem in bug 1733215.

Marco, any ideas on what this might be? It's obviously async in nature but I can't think of what would cause the heuristic to disappear. I'm not sure how to debug it either. Might be a good idea to add a lot of logging so we can ask users to turn it on in cases like this.

Comment 6

[Marco Bonardo [:mak]]

This should not really happen, I wonder if recent changes to heuristic/muxer may have caused a race condition. It's particularly confusing that the heuristic result disappears, that should pretty much never happen.

First thing, please check if you have a keyword set on google.com or maps.google.com in the Search engines list in about:preferences#search, do you have a "g" keyword on any of those there?
Second thing, please search your bookmarks for maps.google.com (you can use the Bookmarks Sidebar or the Library Window), and check if you have a bookmark to it with a "g" keyword.
Based on the screenshots though, that should not be the cause of the problem.

Another useful thing, could you please use the Attach button on this report, and attach a txt with all the contents from about:support?

If we cannot figure this out by these checks and logs, we may have to ask you to help us finding when the problem started, by using https://mozilla.github.io/mozregression/, that would tell us when the problem began and identify the change that caused it.

Comment 7

[talondaniels]

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

This should not really happen, I wonder if recent changes to heuristic/muxer may have caused a race condition. It's particularly confusing that the heuristic result disappears, that should pretty much never happen.

First thing, please check if you have a keyword set on google.com or maps.google.com in the Search engines list in about:preferences#search, do you have a "g" keyword on any of those there?

There is no "g" keyword, only the default "@google". I do have to enable the search shortcut for Google for this bug to appear. When it is not enabled, the url bar behaves as expected.
Search Shortcuts

Second thing, please search your bookmarks for maps.google.com (you can use the Bookmarks Sidebar or the Library Window), and check if you have a bookmark to it with a "g" keyword.

No bookmarks for maps.google.com. All google.com bookmarks

Based on the screenshots though, that should not be the cause of the problem.

Another useful thing, could you please use the Attach button on this report, and attach a txt with all the contents from about:support?
Added

If we cannot figure this out by these checks and logs, we may have to ask you to help us finding when the problem started, by using https://mozilla.github.io/mozregression/, that would tell us when the problem began and identify the change that caused it.

Comment 8

[talondaniels]

Attachment: firefoxaboutsupport.txt

Comment 9

[talondaniels]

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

This should not really happen, I wonder if recent changes to heuristic/muxer may have caused a race condition. It's particularly confusing that the heuristic result disappears, that should pretty much never happen.

First thing, please check if you have a keyword set on google.com or maps.google.com in the Search engines list in about:preferences#search, do you have a "g" keyword on any of those there?
Second thing, please search your bookmarks for maps.google.com (you can use the Bookmarks Sidebar or the Library Window), and check if you have a bookmark to it with a "g" keyword.
Based on the screenshots though, that should not be the cause of the problem.

Another useful thing, could you please use the Attach button on this report, and attach a txt with all the contents from about:support?

If we cannot figure this out by these checks and logs, we may have to ask you to help us finding when the problem started, by using https://mozilla.github.io/mozregression/, that would tell us when the problem began and identify the change that caused it.

This mozregression tool is pretty awesome. I was able to narrow it down to this build I think:

app_name: firefox
build_date: 2021-06-19 00:49:51.512000
build_type: integration
build_url: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/SWFFJY90QliflblmR6R55g/runs/0/artifacts/public%2Fbuild%2Ftarget.zip
changeset: 978ada486e18fd620352a9461090fdfc3bc256a4
pushlog_url: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=3c85001a3794d525e621d872c1abc4d4cd1b2af9&tochange=978ada486e18fd620352a9461090fdfc3bc256a4
repo_name: autoland
repo_url: https://hg.mozilla.org/integration/autoland
task_id: SWFFJY90QliflblmR6R55g

or maybe this is more helpful:

2021-12-21T20:39:48.920000: INFO : application_buildid: 20210618230751
2021-12-21T20:39:48.920000: INFO : application_changeset: 978ada486e18fd620352a9461090fdfc3bc256a4
2021-12-21T20:39:48.920000: INFO : application_display_name: Firefox Nightly
2021-12-21T20:39:48.920000: INFO : application_id: {ec8030f7-c20a-464f-9b0e-13a3a9e97384}
2021-12-21T20:39:48.921000: INFO : application_name: Firefox
2021-12-21T20:39:48.921000: INFO : application_remotingname: firefox
2021-12-21T20:39:48.921000: INFO : application_repository: https://hg.mozilla.org/integration/autoland
2021-12-21T20:39:48.921000: INFO : application_vendor: Mozilla
2021-12-21T20:39:48.921000: INFO : application_version: 91.0a1
2021-12-21T20:39:48.921000: INFO : platform_buildid: 20210618230751
2021-12-21T20:39:48.921000: INFO : platform_changeset: 978ada486e18fd620352a9461090fdfc3bc256a4
2021-12-21T20:39:48.922000: INFO : platform_repository: https://hg.mozilla.org/integration/autoland
2021-12-21T20:39:48.922000: INFO : platform_version: 91.0a1
2021-12-21T20:40:14.255000: INFO : Narrowed integration regression window from [3c85001a, 6d77c5cd] (3 builds) to [3c85001a, 978ada48] (2 builds) (~1 steps left)
2021-12-21T20:40:14.260000: DEBUG : Starting merge handling...
2021-12-21T20:40:14.260000: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=978ada486e18fd620352a9461090fdfc3bc256a4&full=1
2021-12-21T20:40:14.260000: DEBUG : redo: attempt 1/3
2021-12-21T20:40:14.260000: DEBUG : redo: retry: calling _default_get with args: ('https://hg.mozilla.org/integration/autoland/json-pushes?changeset=978ada486e18fd620352a9461090fdfc3bc256a4&full=1',), kwargs: {}, attempt #1
2021-12-21T20:40:14.262000: DEBUG : urllib3.connectionpool: Resetting dropped connection: hg.mozilla.org
2021-12-21T20:40:14.997000: DEBUG : urllib3.connectionpool: https://hg.mozilla.org:443 "GET /integration/autoland/json-pushes?changeset=978ada486e18fd620352a9461090fdfc3bc256a4&full=1 HTTP/1.1" 200 None
2021-12-21T20:40:15.026000: DEBUG : Found commit message:
Bug 1717248 - Remove non-existing file from moz.configure. r=firefox-build-system-reviewers,nalexander

This fixes it for me. I believe this is right because the file it was inlined
into in D117711 is also on this list.

Differential Revision: https://phabricator.services.mozilla.com/D118277

2021-12-21T20:40:15.026000: DEBUG : Did not find a branch, checking all integration branches
2021-12-21T20:40:15.027000: INFO : The bisection is done.
2021-12-21T20:40:15.028000: INFO : Stopped

Bisection Results

Comment 10

[Marco Bonardo [:mak]]

Unfortunately the bisection doesn't look right, maybe the issue is intermittent, because the pointed at changeset cannot have caused this bug.
Sometimes it happens, especially with bugs that are not trivial to reproduce. I know it's time consumingm, but maybe you could do a second try and see if the range differs.
If the actual cause is effectively around that time, the following bugs could have caused the issue: Bug 1662172, Bug 1714409, Bug 1713322
That seems plausible, even if we don't have the exact reason.

From about:support log I see you set browser.urlbar.maxRichResults: 3, does the issue go away if you set it back to the default value, even just temporarily for testing?

Comment 11

[Drew Willcoxon :adw]

I can reproduce the disappearing heuristic on a new profile if I set maxRichResults to 3 and trigger a tab-to-search. When I press Enter Firefox loads the expected Google SERP for what I typed though. I'll investigate.

Comment 12

[Drew Willcoxon :adw]

mozregression points to bug 1712575 for the disappearing heuristic problem. I don't know if that's the entirety of what the reporter is reporting. That timeline is plausible for bug 1733215 too.

Comment 13

[Drew Willcoxon :adw]

Below is what happens in the muxer when I type "go" with maxRichResults=3. The muxer's sort() is called 4 times. I'll describe the initial context.results at the start of the call and sortedResults at the end of the call.

1. • context.results (2): search heuristic, autofill heuristic for google.com
   • sortedResults (1): autofill heuristic for google.com
2. • context.results (3): autofill heuristic for google.com, 2 of the exact same onboarding tab-to-search (TTS)
   • sortedResults (1): onboarding TTS
3. • context.results (3): onboarding TTS, Places https://www.google.com/, Places https://www.google.com/?gws_rd=ssl
   • sortedResults (2): Places https://www.google.com/, onboarding TTS
4. • context.results (6): Places https://www.google.com/, onboarding TTS, 4 google search suggestions
   • sortedResults (2): 1 google search suggestion, onboarding TTS

The muxer is doing the right thing at each step, or at least the thing it's designed to do. It assumes we always want to show suggested-index results, so throwing away the autofill heuristic in step 2 is correct because context.results contains 2 suggested-index results each with a result span of 2, and the max count/span is only 3.

Bug 1712575 regressed this because before that the muxer added suggested-index results at the end of the sort without first making room for them, so the autofill result had a chance to be added to sortedResults.

Not sure how we should fix this. I still think making room for suggested-index results at the start of the sort is the right idea.

And there's the other part the reporter describes, where pressing Enter visits maps.google.com, which isn't even present in the final results. I think what's happening there is the maps.google.com result was the last one to be selected in the view, which means UrlbarInput uses that result as its current value (_resultForCurrentValue) when Enter is pressed.

Since things like this will only happen for small non-standard maxRichResults values, I think a medium priority for this is right, as opposed to a high priority. The reporter in bug 1733215 indicated their maxRichResults was 12 though (comment 7), but their screen recording looks like it's more like 4.

Comment 14

[Drew Willcoxon :adw]

I think we should do this:

• As long as maxRichResults is > 0, always make room for the heuristic, even if it means we must discard a suggested-index result
  • Or simply don't discard the suggested-index result(s) at all -- just go over the maxRichResults count, no big deal
• Add a special case for TTS results: Make room for only one TTS even when multiple are present
  • Or maybe this could be generalized to: If a provider returns more than one suggested-index result with the same suggested index, assume the intention is that only one will be shown. Probably we should do the special case and punt the generalization to bug 1670185 or some time later when it would be useful for more than the TTS provider.

Comment 15

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1712575

Comment 16

[Drew Willcoxon :adw]

Oh, I assumed UrlbarProviderTabToSearch adds two results for some searches since it has two different chunks where it adds results, but that's not true. It's incidentally adding two results because UrlbarSearchUtils.enginesForDomainPrefix() can include the same engine more than once in the array it returns, which seems like a bug.

Edit: It can add multiple results per search of course, by design (see bug 1647927). What I'm seeing is that Google ends up being added twice due to what I mentioned above. So there are two concerns here: (1) Fixing that duplication bug, (2) modifying the muxer for TTS as mentioned in comment 14.

Comment 17

[Drew Willcoxon :adw]

https://treeherder.mozilla.org/jobs?repo=try&revision=f254f2f6464dd8f9f9512f8f38c9497835354796

Comment 18

[Drew Willcoxon :adw]

Attachment: Bug 1744367 - Part 1: Always make room for the heuristic result when maxRichResults > 0.

The problem (as described in the bug) is that the user's maxRichResults is 3
and the tab-to-search provider returns two onboarding results, so when the muxer
subtracts the total result span (4) of those two results from the available span
(3), there's no room left for the heuristic. On top of that, there's the usual
async nature of fetching results where the muxer's sort() gets called multiple
times per query, so the heuristic can briefly appear before the TTS results
arrive and push it out.

This part-1 patch forces the available result span to be no smaller than the
largest heuristic result span when maxRichResults is positive. That way a
heuristic will always be included regardless of whatever suggested-index results
are present or whatever result spans the heuristic and suggested-index results
have.

This also fixes a potential other problem when the heuristic is hidden but has a
result span larger than 1. Currently we just increment the available span to
compensate, but it should be increased by the heuristic's result span.

For both of the two fixes mentioned above, this patch uses the largest heuristic
result span when there are multiple heuristics. The muxer can't know which
heuristic will end up winning in the end at the time it needs to make these
adjustments to the available span, so it could be the case that the largest
heuristic span is not the span of the final heuristic. But in that case the only
consequence is that the list of results will have fewer results than necessary.

Comment 19

[Drew Willcoxon :adw]

Attachment: Bug 1744367 - Part 2: Account for only one tab-to-search result when adjusting the muxer's available result span.

This makes the muxer account for only one TTS result when it adjusts the
available result span. Currently it accounts for however many TTS results are
added by the provider even though only one will be included in the end.

Like the part-1 patch (D134771), this patch uses the largest TTS result span
when there are multiple TTS results. The muxer can't know which TTS will end up
winning in the end at the time it needs to make the adjustment to the available
span, so it could be the case that the largest TTS span is not the span of the
final TTS. But it's unlikely that multiple TTS results in one query will have
different spans, and in that case the only consequence is that the list of
results will have fewer results than necessary.

Depends on D134771

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/516d3166a519
Part 1: Always make room for the heuristic result when maxRichResults > 0. r=harry
https://hg.mozilla.org/integration/autoland/rev/e0ebfe518fa9
Part 2: Account for only one tab-to-search result when adjusting the muxer's available result span. r=harry

Comment 21

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/516d3166a519
https://hg.mozilla.org/mozilla-central/rev/e0ebfe518fa9

Comment 22

[Cristian Baica [:cbaica], Release Desktop QA]

I've managed to reproduce the issue using Fx96.0a1, with the setting Drew mentioned in comment 11.
The issue is verified fixed in the latest Fx97.0a1 on Windows 10 and Ubuntu 20.04. The 'google.com' is correctly autocompleted and correctly navigated to using the same settings with which the issue was occuring.