Closed Bug 1675926 Opened 3 months ago Closed 2 months ago

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

Categories

(Firefox :: Address Bar, defect, P1)

Firefox 83
defect
Points:
3

Tracking

()

RESOLVED FIXED
85 Branch
Iteration:
85.1 - Nov 16 - Nov 29
Tracking Status
firefox84 --- fixed
firefox85 --- fixed

People

(Reporter: lucas.werkmeister, Assigned: harry)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

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.

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

Component: Untriaged → Address Bar

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?

Flags: needinfo?(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.

Flags: needinfo?(lucas.werkmeister)

I can also reproduce this in the latest Nightly.

Severity: -- → S3
Status: UNCONFIRMED → NEW
Points: --- → 3
Ever confirmed: true
Priority: -- → P1
Summary: Address bar shows empty keyword search when switching tabs while loading search results → Tab does not exit search mode after a location change if it is switched away from quickly
See Also: → 1677325

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

Assignee: nobody → htwyford
Status: NEW → ASSIGNED
Iteration: --- → 85.1 - Nov 16 - Nov 29

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.

Pushed by htwyford@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/6d497ff31793
Do not restore search mode if pageproxystate is valid. r=adw
Status: ASSIGNED → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → 85 Branch

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:
Attachment #9189228 - Flags: approval-mozilla-beta?

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

approved for 84.0b5

Attachment #9189228 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Duplicate of this bug: 1679497
You need to log in before you can comment on or make changes to this bug.