I didn't initially add it to Fenix/GV because I wanted to keep the bug focused on the session history pieces and also wanted to give the mobile team a chance to evaluate this independently (the back button might work slightly differently on mobile). As mentioned, it should in theory be easy to add once this is available on central. I filed bug 1644595 for continuing that discussion.
Thanks for calling that out! On Tue, Jun 9, 2020 at 11:30 PM <asfe...@mozilla.com> wrote: > 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 > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
