1792634 - On flaky/slow connection, if you search with "? search-term" in address bar and reattempt the load, you can end up searching for your search URL instead of your search term

Status: ASSIGNED

(Firefox :: Address Bar, defect, P3)

Description

[Daniel Holbert [:dholbert]]

Attachment: Screencast from 09-27-2022 04:18:21 PM.webm

STR:

1. (optional but helpful) : Be on a flaky connection (I'm at all-hands right now in a room full of people, where the network is intermittently working)
2. Focus the URL bar and type ? example and hit enter (to search for the term "example")
3. Pretend you've been waiting for a bit. Focus the URL bar with Ctrl+L and hit enter to reattempt the load.

EXPECTED RESULTS:

• At some point after step 2, your URL bar should atomically update to lose the [Google] badge and show the expanded search URL.
• Step 3 should just reattempt the load of your search results.

ACTUAL RESULTS:

• After step 2, your URL bar first expands the search term to show the search URL (e.g. https://www.google.com/search?client=firefox-b-1-d&q=example) before the [Google] badge disappears.
• In step 3, you end up searching for https://www.google.com/search?client=firefox-b-1-d&q=example so you end up looking at https://www.google.com/search?client=firefox-b-1-d&q=https%3A%2F%2Fwww.google.com%2Fsearch%3Fclient%3Dfirefox-b-1-d%26q%3Dexample (i.e. google search results with the google search URL being the query)

See attached screencast.

Comment 1

[Daniel Holbert [:dholbert]]

I can reproduce this quite reliably if I run the following command to throttle my bandwidth with wondershaper (on Ubuntu 22.04).:

sudo wondershaper  wlp0s20f3 100 100

(replace wlp0s20f3 with your own network interface taken from e.g. ifconfig)

After running this command, I remain in the "limbo" state with [Google] and the fully-expanded search URL (the first "ACTUAL RESULT") for a long time, which puts us at risk of running into trouble if the user focuses the URLbar and hits enter (step 3 of the STR).

Comment 2

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert][mostly away until Oct 6] from comment #0)

ACTUAL RESULTS:

• After step 2, your URL bar first expands the search term to show the search URL (e.g. https://www.google.com/search?client=firefox-b-1-d&q=example) before the [Google] badge disappears.

This is visible at 0:02s - 0:03s in my attached screencast.

• In step 3, you end up searching for https://www.google.com/search?client=firefox-b-1-d&q=example so you end up looking at https://www.google.com/search?client=firefox-b-1-d&q=https%3A%2F%2Fwww.google.com%2Fsearch%3Fclient%3Dfirefox-b-1-d%26q%3Dexample (i.e. google search results with the google search URL being the query)

This is visible at 0:04s in my attached screencast (and afterwards, though I happened to have a notification appear at 0:05s which sort of blocks the URL bar and makes it harder to see).

Comment 3

[Daniel Holbert [:dholbert]]

Here's a profile of me reproducing the issue (after using wondershaper to throttle my bandwidth, per comment 1):
https://share.firefox.dev/3replcE

If you look carefully at the screenshots track, you can see the example search term expanding to the full google search URL, with the [Google] search badge still present, which is the problematic state (first ACTUAL RESULT) that causes further issues after additional user input (second ACTUAL RESULT).

Comment 4

[Daniel Holbert [:dholbert]]

Regression range:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e6fa159738fa2f0b460c3867d0b4d439d64e59cd&tochange=508a0cc2f6d446e4b016ebb6d2c740c80f830dd9 [EDIT, this was wrong -- see next comment]

(When getting this regression range, I had to use "Ctrl+K" in older builds -- rather than ? -- in order for the [Google] badge to show up, which seems to be necessary to trigger this bug.)

Comment 5

[Daniel Holbert [:dholbert]]

sorry, looks like my regression range in comment 4 was off by one day actually; I probably messed something up at the last step. I re-ran mozregression with a few days on either side to confirm, and it looks like the correct range is one day later than I had initially had in comment 4.

Regression range:
Last good revision: 508a0cc2f6d446e4b016ebb6d2c740c80f830dd9 (2020-08-17)
First bad revision: 069bb8bd2356b4d5738e1cec37bf561c24c0f923 (2020-08-18)
Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=508a0cc2f6d446e4b016ebb6d2c740c80f830dd9&tochange=069bb8bd2356b4d5738e1cec37bf561c24c0f923

In that range, Bug 1659128 looks like the most likely candidate. adw, maybe you could take a look here?

Comment 6

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

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

Comment 7

[Drew Willcoxon :adw]

Thanks for the regression hunting, looks like a plausible regressed-by.

Comment 8

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

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

Comment 9

[Donal Meehan [:dmeehan]]

Looks like it's too late for 107.
:adw do you plan on fixing this for 108?

Comment 10

[Drew Willcoxon :adw]

Sorry, I haven't had time to work on this. It will probably have to be 109 at the earliest.