1742899 - Back button randomly stops working properly (private browsing)

Status: VERIFIED FIXED

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

Description

[enterent]

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

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

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.

Comment 2

[joant]

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.

Comment 3

[Jzatar2]

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

Comment 4

[Alice0775 White]

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=87c6360e23c21705b112dda28895c50d0280da75&tochange=10bc715228c379d46953ff4581d4fbf72141218d

Comment 5

[enterent]

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/

Comment 6

[enterent]

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?

Comment 7

[Tomer Yavor]

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.

Comment 8

[Christoph Kerschbaumer [:ckerschb]]

Niklas is on it!

Comment 9

[Niklas]

Attachment: Bug 1742899: Exempt history entry loads from https-first mode. r=ckerschb!,smaug!

Comment 10

[Niklas]

Attachment: Bug 1742899: Test back button for http only sites with https-first enabled. r=ckerschb!,smaug

Depends on D132566

Comment 11

[Pulsebot]

Pushed by [e-mail]:
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

Comment 12

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/853d982bb4cf
https://hg.mozilla.org/mozilla-central/rev/945d3d375a73

Comment 13

[joant]

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

Should I open a new bug for it?

Comment 14

[Christoph Kerschbaumer [:ckerschb]]

(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

[Ryan VanderMeulen [:RyanVM]]

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

Comment 16

[Christoph Kerschbaumer [: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

Comment 17

[Dianna Smith [:diannaS]]

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

Approved for 96.0b5

Comment 18

[Dianna Smith [:diannaS]]

https://hg.mozilla.org/releases/mozilla-beta/rev/c3cae0017b50
https://hg.mozilla.org/releases/mozilla-beta/rev/06667a53c04f

Comment 19

[Giorgia Nichita, Release Desktop QA]

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.