Closed Bug 1742899 Opened 3 years ago Closed 3 years ago

Back button randomly stops working properly (private browsing)

Categories

(Core :: DOM: Navigation, defect, P3)

Firefox 94
defect

Tracking

()

VERIFIED FIXED
97 Branch
Tracking Status
firefox-esr91 --- wontfix
firefox94 --- wontfix
firefox95 --- wontfix
firefox96 --- verified
firefox97 --- verified

People

(Reporter: enterent, Assigned: n.goeggi)

References

(Blocks 2 open bugs, Regression)

Details

(Keywords: regression, reproducible)

Attachments

(2 files)

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

Steps to reproduce:

I don't know neither the exact steps to reproduce it nor what causes it, but I know the circumstances.
When it happens to, it's always when I'm using private browsing, but never when I'm using normal browsing. If it's not related to private browsing, then it's a huge coincidence.
Also, it usually happens when i have more than a few tabs open in my private browsing window (to be specific - about 10), and it usually happens at one of more recently opened tabs, however I think that this might be coincidental.
Also, it's worth noting that this bug might be universal - I had to use a different pc for a few days, and it also happened there. That pc had a totally different configuration than the first one.
Also, it's not very recent - it has been happening maybe since summer.

Actual results:

Let's say that I open a new private browsing tab, and I go to site/page A. From there, I click a link and go to site/page B. From there i go to C. So it's like this:
A -> B -> [C]
(active page marked in brackets)
I click back, and it goes to B, as expected. Except that it doesn't go back. It goes "forward". If I click back again, it goes to C again, and from there it is infinite loop:
A -> B -> C -> B -> [C] ...
However, if I right click back button, and select A manually, it goes back to A correctly.

Expected results:

It should have gone "backward" to B, not "forward".

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

Component: Untriaged → DOM: Navigation
Product: Firefox → Core

I have a 100% reproducer on this bug, tested on FF 94.0.1/Win64 and 94.0/aarch64/Linux. Confirmed this bug does NOT occur on FF 78.12.0esr/Linux/x86_64.

  1. start a clean Firefox, no addons, default profile, etc.
  2. Visit http://bitsavers.org/pdf
  3. Click on 3Com (first directory entry)
  4. Click on 3+Open (first directory entry)
  5. Click on Back. Browser should display "Index of /pdf/3Com".
  6. Click on Back again. Browser should display "Index of /pdf" - CORRECT
  7. Open a private window
  8. Repeat steps 2-6. Browser will incorrectly display "Index of pdf/3Com/3+Open", and the history in the Back arrow dropdown will have grown in length.

Based on my poor memory of noticing this problem appear, I believe this issue was introduced somewhere around FF 92 -- but I cannot confirm.

can also confirm Joan's steps reproduce on 94.0/amd64/Linux.

Blocks: backtraps
Status: UNCONFIRMED → NEW
Has STR: --- → yes
Ever confirmed: true
Keywords: reproducible

It happened to me again, twice. I noted the sites, started looking if anything is similar between them, and noticed, that both of them are unencrypted. I can easily reproduce it on those sites. The site joant linked above is also unencrypted. It must be related.

Another example where this happens:
http://www.romanheritage.com/en/portada/

Some new weird behaviour related to this started happening. Previously, when pages were repeating themselves in the right-click menu, they all had correct page titles. Now, only the newest two have page titles, while the rest have URLs:
https://i.imgur.com/3mjDgTX.png
Also, if I manually click the first page, as I've described above, now it doesn't go back, but instead gives me an connection error (PR_CONNECT_RESET_ERROR)
I tested this on 2 PCs, same on both.
This is very recent, might have something to do with changes introduced in 94.0.2?

Assignee: nobody → lyavor

Seems like that bug only occurs on http sites ( @enterent if I open romanheritage.com it doesn't get upgraded to https - but on your screenshots the scheme is https but still the problem also occurs on that website).

Might be related to https://bugzilla.mozilla.org/show_bug.cgi?id=1725402 or https://bugzilla.mozilla.org/show_bug.cgi?id=1721448.
I will investigate it.

Severity: -- → S2
Flags: needinfo?(ckerschb)
Priority: -- → P3
Assignee: lyavor → ngogge
Status: NEW → ASSIGNED

Niklas is on it!

Flags: needinfo?(ckerschb)
Pushed by mozilla@christophkerschbaumer.com: https://hg.mozilla.org/integration/autoland/rev/853d982bb4cf Exempt history entry loads from https-first mode. r=ckerschb,smaug https://hg.mozilla.org/integration/autoland/rev/945d3d375a73 Test back button for http only sites with https-first enabled. r=smaug,ckerschb
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 97 Branch

Please reconsider fixing this in 91esr . This affects multiple corporate installations at my clients.

Should I open a new bug for it?

Flags: needinfo?(ngogge)

(In reply to joant from comment #13)

Please reconsider fixing this in 91esr . This affects multiple corporate installations at my clients.

Ryan, what's your take? I don't know about timing; the patch itself is rather small and could be uplifted with a risk assessment of low. If you think it's worth doing, I could file the uplift request.

Flags: needinfo?(ryanvm)

Let's start with getting this on to Beta and go from there.

Flags: needinfo?(ryanvm) → needinfo?(ckerschb)

Comment on attachment 9253208 [details]
Bug 1742899: Exempt history entry loads from https-first mode. r=ckerschb!,smaug!

Beta/Release Uplift Approval Request

  • User impact if declined: We have been shipping https-first, which upgrades top-level loads from http to https since Firefox 91 in Private Browsing Windows. Due to this history back the back button sometimes stops working properly.
  • 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): It's a very self-contained fix for https-first which only exempts history loads from https-first, since at the time when the history entry is created we already know if the upgrade to https succeeded in the first place.
  • String changes made/needed: no
Flags: needinfo?(ckerschb)
Attachment #9253208 - Flags: approval-mozilla-beta?
Attachment #9253231 - Flags: approval-mozilla-beta?

Comment on attachment 9253208 [details]
Bug 1742899: Exempt history entry loads from https-first mode. r=ckerschb!,smaug!

Approved for 96.0b5

Attachment #9253208 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #9253231 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Flags: qe-verify+
QA Whiteboard: [qa-triaged]

I was able to reproduce this issue on an affected Nightly build 96.0a1 (2021-11-24) using the STR from Comment 2, on Win 10 x64.

Verified as fixed on 96.0b5 (20211214203716) and 97.0a1 (20211214213409) across the following platforms: Win 10 x64, Ubuntu 20.04 and macOS 10.15.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
Flags: needinfo?(ngogge)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: