On Tuesday, June 9, 2020 at 2:17:02 PM UTC-7, Johann Hofmann wrote: > In bug 1515073 <https://bugzilla.mozilla.org/show_bug.cgi?id=1515073> I > plan to land an intervention that is aimed to reduce user frustration from > an issue with malfunctioning or malicious websites which is commonly known > as the “broken back button”. > > For user-initiated session history interactions, such as pressing the back > button or opening the back/forward menu, we want to only consider the first > session history entries that were created after the associated document > received a user interaction event. This means that when a document has user > interaction and a new session history entry is added, that entry “consumes” > the user interaction from the document and the next entry will again > require a new user interaction on the document. > > Both the first (earliest) and last (latest) session history entries will > always be available for navigation. > > Note that this explicitly does not change the behavior of any web-exposed > APIs such as history.back(). > > Some more details can be found in this document > <https://docs.google.com/document/d/1eK5xcWo1T7M-SguRshahy53zHMvkvVzxIjVWZm34o-U/edit#> > . > > I’m planning to land and enable this in Nightly 79, but want to leave > sufficient bake time to be confident that it’s not breaking any critical > functionality. We're expecting this to ride the trains with at least > version 80 or later. > > Standard: This feature is not standardized though there has been a public > discussion in https://github.com/WICG/interventions/issues/21 > > Platform coverage: This will land enabled in desktop only for now, but it’s > built in a way that should make it easy for Android browsers to add support. > > Preference: On desktop this is behind the preference > “browser.navigation.requireUserInteraction”. It will be set to true in > Nightly by default. > > DevTools: This is not yet integrated into devtools though we should > consider logging a warning to the console when we skip an entry. > > Other browsers: > > Chrome: Shipped last year > <https://groups.google.com/a/chromium.org/forum/?#!msg/blink-dev/T8d4_BRb2xQ/WSdOiOFcBAAJ>. > Our implementation is following their approach and we’ve seen several web > compat bugs from sites relying on this behavior from Chrome. > > Safari: No public signals > > Let me know if you have any questions or concerns, > > Thanks! > > Johann
This is really nice! > Platform coverage: This will land enabled in desktop only for now, but it’s built in a way that should make it easy for Android browsers to add support. I'm wondering why this is landing as Desktop only? Could you share the bug for supporting this on mobile? Thanks, Agi _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
