1675926 - Tab does not exit search mode after a location change if it is switched away from quickly

Status: RESOLVED FIXED

(Firefox :: Address Bar, defect, P1)

Description

[Lucas Werkmeister]

Attachment: Screenshot from 2020-11-07 13-39-05.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:83.0) Gecko/20100101 Firefox/83.0

Steps to reproduce:

1. Open a new tab
2. Type a search keyword and a search term, e. g. w test (if w = Wikipedia)
3. Press <kbd>Enter</kbd>, then quickly switch to another tab in the same window, or open a new tab

Actual results:

After the search result page has loaded, the Awesome Bar shows the title of the search keyword next to an empty search field.

Expected results:

It should show the URL of the currently loaded page.

Comment 1

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

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

Comment 2

[Marco Bonardo [:mak]]

It sounds like a race condition, but as far as I try I cannot reproduce, though I tried on Windows only yet.
Woul you have a change to test Nightly and check if the problem is still present in it?

Comment 3

[Lucas Werkmeister]

I was able to reproduce the issue in Nightly 84.0a1 (about:support build ID 20201111095506, firefox-nightly AUR package version 84.0a1.20201111-1) in a fresh profile using the default @wikipedia search keyword. (Well, it’s in the same preferences section as the search keywords I’m used to, not sure if the @ signifies something different.

Comment 4

[Harry Twyford]

I can also reproduce this in the latest Nightly.

Comment 5

[Harry Twyford]

It's worth pointing out that this is the case Drew says we don't yet handle in bug 1659128 comment 2.

Comment 6

[Harry Twyford]

Attachment: Bug 1675926 - Do not restore search mode if pageproxystate is valid. r?adw

We were restoring search mode after tab switch even if the destination tab had a valid pageproxystate. This was causing issues in the case where the user switched away from a tab that was still loading and had not yet called setURI. If the user switched back to that tab after it was done loading, we would re-enter search mode, using the page's URL as the search string.

Making this change also requires storing pageproxystate differently. If we only made the change to setURI, we would sometimes not restore search mode when we should. If the user entered search mode with an empty string, userTypedValue would never be updated and it would still be the page URL. After the user switched from, then to, that tab, we'd call setURI. setURI would restore userTypedValue, which would be the page URL. Since that page now had a valid pageproxystate, we would not restore search mode. Now we update userTypedValue when we enter search mode, so we restore search mode properly even when there is no search string.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6d497ff31793
Do not restore search mode if pageproxystate is valid. r=adw

Comment 8

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/6d497ff31793

Comment 9

[Harry Twyford]

Comment on attachment 9189228 [details]
Bug 1675926 - Do not restore search mode if pageproxystate is valid. r?adw

Beta/Release Uplift Approval Request

• User impact if declined: Users can run into a timing issue where they are in search mode when they shouldn't be. This is annoying and detracts from the search mode experience.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Extensive tests for a small change. Only affects the front-end. The patch has baked on Nightly for several days with no issues.
• String changes made/needed:

Comment 10

[Julien Cristau [:jcristau]]

Comment on attachment 9189228 [details]
Bug 1675926 - Do not restore search mode if pageproxystate is valid. r?adw

approved for 84.0b5

Comment 11

[Julien Cristau [:jcristau]]

https://hg.mozilla.org/releases/mozilla-beta/rev/2adcfd8d1968