Back button randomly stops working properly (private browsing)
Categories
(Core :: DOM: Navigation, defect, P3)
Tracking
()
People
(Reporter: enterent, Assigned: n.goeggi)
References
(Blocks 2 open bugs, Regression)
Details
(Keywords: regression, reproducible)
Attachments
(2 files)
(deleted),
text/x-phabricator-request
|
diannaS
:
approval-mozilla-beta+
|
Details |
(deleted),
text/x-phabricator-request
|
diannaS
:
approval-mozilla-beta+
|
Details |
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".
Comment 1•3 years ago
|
||
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.
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.
- start a clean Firefox, no addons, default profile, etc.
- Visit http://bitsavers.org/pdf
- Click on 3Com (first directory entry)
- Click on 3+Open (first directory entry)
- Click on Back. Browser should display "Index of /pdf/3Com".
- Click on Back again. Browser should display "Index of /pdf" - CORRECT
- Open a private window
- 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.
Updated•3 years ago
|
Updated•3 years ago
|
Comment 4•3 years ago
|
||
Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=87c6360e23c21705b112dda28895c50d0280da75&tochange=10bc715228c379d46953ff4581d4fbf72141218d
Updated•3 years ago
|
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?
Updated•3 years ago
|
Comment 7•3 years ago
|
||
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.
Updated•3 years ago
|
Assignee | ||
Comment 10•3 years ago
|
||
Depends on D132566
Comment 11•3 years ago
|
||
Comment 12•3 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/853d982bb4cf
https://hg.mozilla.org/mozilla-central/rev/945d3d375a73
Updated•3 years ago
|
Comment 13•3 years ago
|
||
Please reconsider fixing this in 91esr . This affects multiple corporate installations at my clients.
Should I open a new bug for it?
Comment 14•3 years ago
|
||
(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.
Comment 15•3 years ago
|
||
Let's start with getting this on to Beta and go from there.
Comment 16•3 years ago
|
||
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 fromhttp
tohttps
since Firefox 91 in Private Browsing Windows. Due to this history back theback
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 tohttps
succeeded in the first place. - String changes made/needed: no
Updated•3 years ago
|
Comment 17•3 years ago
|
||
Comment on attachment 9253208 [details]
Bug 1742899: Exempt history entry loads from https-first mode. r=ckerschb!,smaug!
Approved for 96.0b5
Updated•3 years ago
|
Comment 18•3 years ago
|
||
bugherder uplift |
Updated•3 years ago
|
Updated•3 years ago
|
Comment 19•3 years ago
|
||
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.
Updated•1 year ago
|
Description
•