PSA: History Manipulation Intervention

2420 views
Skip to first unread message

Shivani Sharma

unread,
May 7, 2019, 3:08:04 PM5/7/19
to blin...@chromium.org
(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

Specification: 

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

Launch bug (internal only)



mree...@gmail.com

unread,
May 12, 2019, 6:08:21 PM5/12/19
to blink-dev
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

unread,
May 13, 2019, 6:56:48 PM5/13/19
to mree...@gmail.com, blink-dev
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

Specification: 

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

Launch bug (internal only)



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

unread,
May 14, 2019, 12:21:39 PM5/14/19
to blink-dev
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

unread,
May 16, 2019, 11:33:36 AM5/16/19
to lior...@gmail.com, blink-dev
(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 (specChrome'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.

hohuu...@gmail.com

unread,
Dec 3, 2019, 3:16:32 PM12/3/19
to blink-dev
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

unread,
Jun 7, 2021, 11:11:22 AM6/7/21
to blink-dev, shiva...@chromium.org, blink-dev, lior...@gmail.com
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

unread,
Jun 7, 2021, 12:40:03 PM6/7/21
to Andrea Puddu, Domenic Denicola, blink-dev, shiva...@chromium.org, lior...@gmail.com
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

eyal sadeh

unread,
Aug 17, 2022, 10:50:27 AM (2 days ago) Aug 17
to blink-dev, mmo...@google.com, blink-dev, shiva...@chromium.org, dom...@google.com
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

Reply all
Reply to author
Forward
0 new messages