On Mon, Dec 5, 2022 at 9:04 AM Weijar Z <weij...@gmail.com> wrote: > 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. > Thanks for raising this! From a user perspective, the browser's back button not landing on the pwa.com's home page is aligned with their expectation because the user did not visit the home page. A possible solution is for pwa.com to have a custom back button inside the app, which when pressed can invoke history.back() and that will take the user to the app's home 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> >>>>> . >>>>> >>>> -- Shivani -- 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/CAORsSEVrz7hLfzUppDWC-PVRBbhxwirUK3g-PHBZ%2BeBRp%2BzP2A%40mail.gmail.com.
