Open Bug 1645211 Opened 4 years ago Updated 15 days ago

[meta] Shipping the back button intervention

Categories

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

task

Tracking

()

People

(Reporter: johannh, Unassigned)

References

(Depends on 7 open bugs, Blocks 9 open bugs)

Details

(Keywords: meta, site-compat)

This is tracking follow-up work to bug 1515073 for shipping a good back button intervention

Keywords: site-compat
Depends on: 1644914
Depends on: 1643554
Depends on: 1644595
Depends on: 1645218
Depends on: 1645220
Depends on: 1645231
Depends on: 1646414
Severity: -- → N/A
See Also: → 1642565
No longer depends on: 1646414
Depends on: 1666095

See also "backtraps" meta bug 340021.

Blocks: backtraps
Depends on: 1731626
Blocks: 1731626
No longer depends on: 1731626
Depends on: 1734181
Blocks: 1703837
Blocks: 1756731
Duplicate of this bug: 1803969
See Also: → 1804305
Duplicate of this bug: 1804465
Duplicate of this bug: 1828286
Duplicate of this bug: 1830113
Duplicate of this bug: 1833420
Duplicate of this bug: 1833317
Depends on: 1776290

I don't want to muddy a meta bug with discussion, but I'm not sure where else to inquire about my dilemma. I tried the Mozilla discourse but had not gotten any traction.

My issue is that this intervention in FireFox breaks single page apps. I understand the need to protect against malicious sites, but this “back button intervention” seems to make history.replaceState() and history.pushState() useless functions. I have a single-page app that will inject a hash on “navigation (hashchange)”. The reason is to allow the user to press the back button to return to the previous page and state (scroll, zoom, etc) while also having that state saved in browser history so that the user can copy/paste the link and get to the same view or return when a session is restored.

When I enable the pref “browser.navigation.requireUserInteraction” the expectation is broken. The history entry is skipped when the back button is pressed. The history.back() function works, so I could implement my own “back button”, but that seems silly.

Is there a way to “properly” use history.replaceState() and history.pushState() such that the browser respects them? How can I be a good citizen in the eyes of the browser and keep some basic functionality?

The below is a minimal example. Serve the webpage with something like python -m http.server. If you click “goto1” and then press the back button you never reach the “#inject” anchor. If you click “goto1” and then press the button for history.back() then you reach the “#inject” anchor. Ideally the back button would reach the anchor as well.

The test works on Microsoft Edge Version 119.0.2151.58 (Official build) (64-bit), what I have on my RHEL9 system.

<html xmlns="http://www.w3.org/1999/xhtml">

<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<script>
function hashTest(event) {
  let newHash = event.newURL.split('#')[1];
  if (newHash == 'goto1') {
    window.history.replaceState({'url': '#inject'}, '', '#inject');
    window.history.pushState({'url': '#' + newHash}, '', '#' + newHash);
  }
}
window.addEventListener('hashchange', hashTest);

</script>
</head>

<body>
<a href="#goto1">Goto1</a>
<button onclick="history.back()">history.back() works correctly</button>
</body>
</html>
Blocks: 1879871
You need to log in before you can comment on or make changes to this bug.