Closed Bug 1879871 Opened 2 years ago Closed 1 year ago

Back navigation can't fight forward redirection

Categories

(Core :: DOM: Navigation, defect)

Firefox 122
defect

Tracking

()

VERIFIED FIXED
Tracking Status
firefox132 --- verified

People

(Reporter: ygoe, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: parity-chrome)

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

Steps to reproduce:

  1. Open https://www.discogs.com/
  2. Enter your favourite song title in the search field and submit
  3. Click on any of the results
  4. Go back (press Alt+Left or click the Back button or use a mouse gesture or whatever)

Actual results:

Nothing

(If you get the expected result, maybe use a browser locale other than en-US. I'm using de-DE here and observe this behaviour for years already.)

Expected results:

I see the results page

Background: When clicking on a result, the page redirects me to another page. That redirection prevents going back again without using the history dropdown menu to select an earlier entry before the previous page.

The same also regularly happens with Microsoft's web SSO mechanism that tends to redirect the browser a couple of times, effectively preventing back navigation with simple inputs (hotkey, toolbutton, mouse gesture).

When navigating back, I'd expect the browser to unwind all automatic redirections of any kind (HTTP header, meta element, JavaScript code) and bring me to the last page I've actually seen before (maybe for at least a couple of seconds or so, for slower-than-immediate redirections).

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

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

In my environment, the first URL does not contain "/ja" directory, but the final URL contains it as the top level directory. I don't reproduce this on Chrome.

farre: Do you know who could take a look?

Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(afarre)
Keywords: parity-chrome

This should be the missing back button intervention. Adam, I added it as a blocker to the meta bug.

Severity: -- → S3
Depends on: 1645211
Flags: needinfo?(afarre) → needinfo?(avandolder)
Flags: needinfo?(avandolder)

The back button intervention has been shipped with bug 1734181.

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED

This looks fixed to me on the Latest Nightly build 132.0a1 across platforms (Windows 11, macOS 13 and Ubuntu 22.04) using the steps from comment 0.

Status: RESOLVED → VERIFIED

Verified as fixed on Android as well, on the latest Nightly 132.0a1 with Samsung Galaxy S23 Ultra (Android 14).

Sorry, but this still doesn't work in Firefox 133 on Windows. I don't agree with the "verified" status at all.

The fix for this has not landed yet in Firefox 133 (release build) but it did in Nightly 132 and was kept in Nightly 135 (nightly build). If you want to have this fixed for you right now you can do the following:

  1. visit about:config
  2. search for browser.navigation.requireUserInteraction and double click on it to make it true
    (but keep in mind that there are a few more fixes that will land only in Firefox 135 so other websites might still have this issue).

Let me know if this worked for you.

Flags: needinfo?(bugzilla)

Interesting that the fix is there in the code but not in the release. Is that normal?

I'll try to report back when I have version 135 release.

(In reply to Yves Goergen [:ygoe] from comment #9)

Interesting that the fix is there in the code but not in the release. Is that normal?

Yep, it's normal on how we handle bug fixes that have to "bake" in a few experimental builds (nightly/beta) before being pushed to the official build (release) just so that the build can be tested after being fixed. In this case it was kept in experimental builds (nightly) for a few versions because multiple websites had the same issue due to different causes so we have to fix most of them before officially saying that the Release build is good now.

I'll try to report back when I have version 135 release.

Thanks!
Looks like Release 135 will receive the official fix but in the meantime if you want to get it sooner (I mean to have that website fixed) just use the instructions from comment 8 right now and it should work for you. The final fix from Release 135 will do the same thing I said in comment 8 but the code will receive additional fixes for other websites that had the same issue as the one from this bug.

Verified for this site in Firefox 135. Thank you!

Flags: needinfo?(bugzilla)
You need to log in before you can comment on or make changes to this bug.