Apologies for the delay. 1. history list: [a.com, b.com]. none of the entries are skippable because a.com got a click and b.com hasn't added any new entry yet. 2. [a.com, b.com, b.com/entry1] again no entry should be skippable since b.com got a user interaction. 3. On reload, there should not be any change in the skippable state of the entries as reloads do not interact with the intervention. Can you check at this point if you long press on the back button, does it show b.com or not. 4. I wonder if there is something about the reload that only leads to one b.com entry and therefore pressing the back button navigates to a.com.
It would be better to create a crbug <https://bugs.chromium.org/p/chromium/issues/entry> for investigating this and continue any follow up discussions on that. On Wed, Aug 17, 2022 at 7:17 AM eyal sadeh <[email protected]> wrote: > Hello! > I experience a use case where this intervention hurts user-experience, > would love to hear your thoughts: > 1. User is on a.com and clicks to go to b.com (Single Page Application). > 2. The user interacts with the page, and a new history entry is created > using pushState. > 3. The user press the reload button (alternatively, in Android, sometimes > the page reloads automatically). > 4. The user press the back button, b.com is skipped, popstate event isn't > triggered, and the user is being navigated to a.com. > > I feel this use case is valid and b.com shouldn't be skipped. I'd suggest > to skip states only if added during the current session. > > Thanks in advance, > Eyal > > On Monday, June 7, 2021 at 7:40:03 PM UTC+3 [email protected] wrote: > >> Hello! >> >> It sounds to me like requesting that Navigations initiated from >> Notification handlers be treated as a user-gesture-initiated would be >> enough to make this use case work correctly. Filed: crbug.com/1217190 if >> that is true. >> >> (The fact that you use history.replace first here likely should not >> affect the situation. So long as the subsequent history.push is treated as >> gesture-initiated you should get the back button behaviour you ask for.) >> >> -Michal >> >> On Mon, Jun 7, 2021 at 11:11 AM Andrea Puddu <[email protected]> wrote: >> >>> Hello, >>> >>> This "intervention" by Chrome is breaking a valid use case in our app >>> (Progressive Web App). >>> >>> Specifically: >>> - users click on a push notification (the app is in background) >>> - notifications open a link, which is e.g. >>> *https://example.app/pwa?noticationId=12345 >>> <https://example.app/pwa?noticationId=12345>* >>> - the PWA opens, it fetches the event associated from the >>> *notificationId*, and redirect to the corresponding view >>> - when users hit the back button we don't want the PWA to be closed >>> immediately: it must redirect to the "home" first >>> >>> To do so, in the notification handler we do: >>> *history.replace(homeURL);* >>> * history.push(eventURL);* >>> >>> Note that this works perfectly fine in Safari, Firefox, etc. because >>> well, it's just using standard APIs. Moreover, this is widely used pattern >>> in native apps: when you click a notification it opens the app, but if you >>> hit the "back button" in Android where does it goes? At the app "home", >>> indeed. >>> >>> This is not pretending to hurt anyone, in fact it is done to improve >>> user's experience. >>> >>> I'm sorry but you need to improve your "intervention" heuristics, you >>> can't break arbitrary apps out there. And this is a B2B app, not a scam >>> website. >>> >>> Thanks, >>> -Andrea >>> >>> El jueves, 16 de mayo de 2019 a las 17:33:36 UTC+2, >>> [email protected] escribió: >>> >>>> (Response inline below.) >>>> >>>> On Tue, May 14, 2019 at 12:21 PM <[email protected]> wrote: >>>> >>>>> How would this affect SPA websites that use push.history to allow >>>>> navigation? >>>>> Could you please clarify what could be the user's gesture? >>>>> Thanks ahead, >>>>> Lior >>>>> >>>> >>>> As long as there is a user gesture on the document either before or >>>> after history.pushState, the intervention would not happen. >>>> User gesture are actions like click (spec >>>> <https://html.spec.whatwg.org/multipage/interaction.html#activation>, >>>> Chrome's >>>> article about user activation >>>> <https://developers.google.com/web/updates/2019/01/user-activation>). >>>> >>>>> >>>>> On Tuesday, May 7, 2019 at 10:08:04 PM UTC+3, Shivani Sharma wrote: >>>>>> >>>>>> (This intervention has been reviewed and approved for launch. As >>>>>> discussed with API owners, announcing the change on blink-dev to ensure >>>>>> that developers are made aware of this change.) >>>>>> >>>>>> Contact emails >>>>>> [email protected], [email protected] >>>>>> >>>>>> Specification: >>>>>> https://github.com/WICG/interventions/issues/21 >>>>>> >>>>>> Summary >>>>>> Some pages makes it difficult or impossible for the user to go back >>>>>> to the page they came from via the browser back button. This is >>>>>> accomplished by redirects or by manipulating the browser history and >>>>>> results in an abusive/annoying user experience. >>>>>> >>>>>> The new behavior of the browser’s back button will be to skip over >>>>>> pages that added history entries or redirected the user without ever >>>>>> getting a user gesture. Note that the intervention only impacts the >>>>>> browser >>>>>> back/forward button UI and not the history.back/forward APIs. >>>>>> >>>>>> Here’s an example: >>>>>> User is on a.com and clicks to go to b.com >>>>>> b.com adds a history entry using pushState or navigates the user to >>>>>> another page (c.com) without ever getting a user gesture. >>>>>> b.com will then be skipped if the user presses back and user will >>>>>> directly be navigated to a.com. >>>>>> >>>>>> Given the above, developers should be aware that if they want the >>>>>> browser’s back button to land on a page that redirected after loading, >>>>>> then >>>>>> that page should have had a user gesture before redirecting. Developers >>>>>> should also be aware that if a history entry is added but there is no >>>>>> user >>>>>> gesture by the time the user hits back, the page adding the history entry >>>>>> will be skipped and the popstate event will not fire. >>>>>> >>>>>> This feature will be supported on all six Blink platforms (Windows, >>>>>> Mac, Linux, >>>>>> Chrome OS, Android, and Android WebView). >>>>>> >>>>>> Tracking bug >>>>>> crbug.com/907167 >>>>>> >>>>>> Launch bug (internal only) >>>>>> crbug.com/909862 >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "blink-dev" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> >>>> To view this discussion on the web visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fd22997b-e4ba-465c-8729-4199270ff6b8%40chromium.org >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fd22997b-e4ba-465c-8729-4199270ff6b8%40chromium.org?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "blink-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> >> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f670be3f-4783-47ca-9f07-f40e8966a19cn%40chromium.org >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f670be3f-4783-47ca-9f07-f40e8966a19cn%40chromium.org?utm_medium=email&utm_source=footer> >>> . >>> >> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADAcp082Ub3ajd7%3DdKn25vQSFGtrmVNiJrHPWgA2F-B%2BWzKuxQ%40mail.gmail.com.
