1913514 - Back navigation can be prevented with some async functions

Status: VERIFIED FIXED

(Core :: DOM: Navigation, defect)

Description

[Full Decent]

Steps to reproduce:

Include this code on target page:

location.search||fetch(0).then(a=>location='?x');

And click back in navigation chrome.

---

Live exploit:

https://fulldecent.github.io/you-cant-leave-this-page-2/

Video narrated explanation:

https://youtu.be/C38e89xqxs0

Actual results:

Does not go back

Expected results:

Goes back

Comment 1

[Full Decent]

Blog post https://blog.phor.net/firefox-zero-day-cant-leave-this-page-2

Comment 2

[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 correct in case you think the bot is wrong.

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Reproduced within the safe mode, but I cannot reproduce this bug with my profile, though. I'm not sure the rules of severity about this kind of issues. Nika, could you set the severity field?

Comment 4

[Nika Layzell [:nika] (ni? for response)]

We don't currently track "user navigation involvement" in quite the way which would be necessary for us to implement this consistently. Doing something like this probably depends on the work for bug 1901045.

I think roughly what we'd want to do if we had this kind of tracking is only allow a load to cancel another "browser UI" load if it at least has "activation" or "browser UI" user navigation involvement, and to cancel the navigation otherwise.

Leaving a ni? for :farre who might have some insight about whether we already have the information required for this.

Comment 5

[Andreas Farre [:farre]]

Yeah, I can't reproduce this, even in safe mode.

I'll forward this to :jjaschke and :avandolder who actually has done recent work with this.

Comment 6

[Jan Jaeschke [:jjaschke]]

I can repro on current Nightly both on MacOS and Ubuntu. Works in Chrome and Safari.

FWIW, in Bug 1904773 I faked "user involvement" by checking if the triggering principal is the system principal. But maybe we should implement the actual thing at some point.

Comment 7

[Hsin-Yi Tsai (she/her) [:hsinyi]]

I couldn't reproduce this on the latest nightly Fx 132. I also verified that if I turned off the preference browser.navigation.requireUserInteraction, I saw the problem.

Comment 8

[Bogdan Maris, Desktop Test Engineering]

Looks fixed to me using the latest Nightly 132 across platforms (Windows 11, macOS 13 and Ubuntu 22.04). If pref browser.navigation.requireUserInteraction is set as true (set to default) this is fixed, if false this will still reproduce.
I'll go ahead and mark this as fixed, please reopen if this is still reproducible for someone.