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 mmo...@google.com 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 <m...@nuragic.io> 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, shiva...@chromium.org >> escribió: >> >>> (Response inline below.) >>> >>> On Tue, May 14, 2019 at 12:21 PM <lior...@gmail.com> 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 >>>>> shiva...@chromium.org, jka...@chromium.org >>>>> >>>>> 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 blink-dev+...@chromium.org. >>>> >>> 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 blink-dev+...@chromium.org. >> > 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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/faa56887-1cb1-46c2-88fc-b9006e9a911en%40chromium.org.
