I want to implement the feature to automatically resume the recently read articles when I open the app. 1. the user opens the address "pwa.com/" 2. App automatically redirects to the last read article "pwa.com/articles/1" But when the user presses back, the app exits directly and it should go back to the article list page.
On Saturday, 29 October 2022 at 03:09:49 UTC+8 shiva...@chromium.org wrote: > 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 <eyals...@gmail.com> 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 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/794b1a84-096b-45ad-978f-c457dcb278a6n%40chromium.org.
