PSA: History Manipulation Intervention

[Shivani Sharma]

(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

[mree...@gmail.com]

Just delay the redirect, show a mandatory piece on top for say 10 seconds giving a cancel (countdown) and an back button (return to previous page) if a redirect is detected. This will stop all the link shenanigans.

[Shivani Sharma]

On Sun, May 12, 2019 at 6:08 PM <mree...@gmail.com> wrote:

Just delay the redirect, show a mandatory piece on top for say 10 seconds giving a cancel (countdown) and an back button (return to previous page) if a redirect is detected. This will stop all the link shenanigans.

Note that the intervention is meant to intervene on redirect without user gesture AND back button. The idea is that workflows relying on redirect AND back API continue to work as usual. Intervening on just the redirect might break valid workflows. 

On Tuesday, May 7, 2019 at 9:08:04 PM UTC+2, 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/565fdeae-fe74-4671-b4b8-416f15b4c28c%40chromium.org.

--

Shivani

[lior...@gmail.com]

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

[Shivani Sharma]

(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, Chrome's article about user activation). 

--
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.

[hohuu...@gmail.com]

Hello,

I wanna ask if this feature has been released to Chrome, because I still see the open issue at https://github.com/WICG/interventions/issues/21

[Andrea Puddu]

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

- 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

[Michal Mocny]

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

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.

[eyal sadeh]

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

[Shivani Sharma]

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 for investigating this and continue any follow up discussions on that.

[Weijar Z]

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.

[Shivani Sharma]

On Mon, Dec 5, 2022 at 9:04 AM Weijar Z <wei...@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.  

--

Shivani