Intent to Ship: History entry requires user gesture

1,480 views
Skip to first unread message

Nate Chapin

unread,
Mar 23, 2018, 6:48:56 PM3/23/18
to blink-dev

Contact emails

jap...@chromium.org


Explainer / Spec

https://github.com/whatwg/html/issues/3524


Summary

This is an intervention that attempts to limit cases where websites create nuisance entries in the back/forward list and reduce the usability of back navigation.


When a non-history navigation occurs, blink decides whether the navigation should create a new entry in the tab's history list, or whether it should replace the current entry. Generally, if the navigation is a reload, uses an API that mandates replacing (i.e., location.replace() or history.replaceState()), or is a content-initiated navigation before onload, the navigation will replace the current entry. Otherwise, a new entry will be created.


This adds one last case where the current entry will be replaced: If (1) the navigation is content-initiated, and (2) the user has never interacted with the Document requesting the navigation, and (3) the Document has been open for less than 5 seconds, then we will replace the current entry. The first clause ensures that user action is given priority in determining what states are useful for potential back navigation. The second clause ensures that Documents can trigger delayed navigations based on user input and assumes that content that has received direct user interaction is more likely to be a desirable back navigation target. The third clause seeks to handle the case where the user spent an extended amount of time on the content and might want to return to it, even if no direct interaction took place (e.g., a media playlist that auto-plays the next item). UseCounter stats indicate that this case triggers on roughly 1 in every 200 Documents.


Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.


Debuggability

This shouldn't need any special integration for debugging. The back/forward list is easily inspectable through the browser UI.

Risks

Interoperability and Compatibility

It is unclear how severe the risk is. History behavior has historically been poorly standardized across browsers, and as a result users and developers alike are regularly surprised by the result of back navigations. As a result, this will almost certainly reduce compatibility in the short run, but it is not certain how much of that will be visible to either users or developers.


On the other hand, there is a cost to having useless back/forward entries and requiring users to repeatedly navigate back to return to the desired content, so it seems like it's worth experimenting to see if we can find a useful behavior to standardize on.



Yoav Weiss

unread,
Apr 2, 2018, 10:58:59 PM4/2/18
to Nate Chapin, blink-dev
LGTM1. This seems like something that will help users avoid having spurious entries in their history, and it seems to me that it will not be hurting any legitimate use cases in the process.

--
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/CACf%3D2L%2BZ7Oj-veet%2BQ_sQ9JAi6Rt%2B%2Bry7J5AZ3bCYcEFMO6%3DjQ%40mail.gmail.com.

Yutaka Hirano

unread,
Apr 2, 2018, 11:23:10 PM4/2/18
to Yoav Weiss, Nate Chapin, blink-dev
Does this mean we cannot have web-platform-tests for history entries?

Chris Harrelson

unread,
Apr 2, 2018, 11:31:34 PM4/2/18
to Yutaka Hirano, Yoav Weiss, Nate Chapin, blink-dev
I left a comment on 

https://github.com/whatwg/html/issues/3524, but I'm concerned about whether we know enough about what legitimate use-cases there are. (Or are there any?) This makes it hard for me to assess compatibility risk.


I certainly have experienced the problem this intent is trying to solve, and agree that it is worth solving.


Chris


Nate Chapin

unread,
Apr 10, 2018, 12:26:18 PM4/10/18
to Chris Harrelson, Yutaka Hirano, Yoav Weiss, blink-dev
It's a bit hard to reason about legitimate vs illegitimate use cases because, outside of the obviously abusive cases intended to trap users, what constitutes a good target for back navigation is highly subjective.  I'm hoping that the criteria listed (i.e., user gesture and time-on-document) will catch all of the important use cases where content is worth going back to.

Anecdotally, I've been browsing with this flag enabled for months and haven't found any broken cases, but anecdotes are only so useful. Unfortunately, I don't see a great way to tell whether this breaks anything meaningful without shipping it and tweaking based off more real knowledge and bug reports as it makes its way toward stable.
~Nate


To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.

Nate Chapin

unread,
Apr 10, 2018, 12:29:22 PM4/10/18
to Yutaka Hirano, Yoav Weiss, blink-dev
I'm open to suggestions on that respect. My initial thought, at least for our test harness, is to have a flag that sets the time threshold for getting a history entry to 0 seconds (i.e., fallback to the legacy behavior for automated testing of most other history behavior).

On Mon, Apr 2, 2018 at 8:22 PM, Yutaka Hirano <yhi...@google.com> wrote:
Does this mean we cannot have web-platform-tests for history entries?

On Tue, Apr 3, 2018 at 11:58 AM Yoav Weiss <yo...@yoav.ws> wrote:
LGTM1. This seems like something that will help users avoid having spurious entries in their history, and it seems to me that it will not be hurting any legitimate use cases in the process.

On Fri, Mar 23, 2018 at 3:48 PM Nate Chapin <jap...@chromium.org> wrote:

Contact emails

jap...@chromium.org


Explainer / Spec

https://github.com/whatwg/html/issues/3524


Summary

This is an intervention that attempts to limit cases where websites create nuisance entries in the back/forward list and reduce the usability of back navigation.


When a non-history navigation occurs, blink decides whether the navigation should create a new entry in the tab's history list, or whether it should replace the current entry. Generally, if the navigation is a reload, uses an API that mandates replacing (i.e., location.replace() or history.replaceState()), or is a content-initiated navigation before onload, the navigation will replace the current entry. Otherwise, a new entry will be created.


This adds one last case where the current entry will be replaced: If (1) the navigation is content-initiated, and (2) the user has never interacted with the Document requesting the navigation, and (3) the Document has been open for less than 5 seconds, then we will replace the current entry. The first clause ensures that user action is given priority in determining what states are useful for potential back navigation. The second clause ensures that Documents can trigger delayed navigations based on user input and assumes that content that has received direct user interaction is more likely to be a desirable back navigation target. The third clause seeks to handle the case where the user spent an extended amount of time on the content and might want to return to it, even if no direct interaction took place (e.g., a media playlist that auto-plays the next item). UseCounter stats indicate that this case triggers on roughly 1 in every 200 Documents.


Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.


Debuggability

This shouldn't need any special integration for debugging. The back/forward list is easily inspectable through the browser UI.

Risks

Interoperability and Compatibility

It is unclear how severe the risk is. History behavior has historically been poorly standardized across browsers, and as a result users and developers alike are regularly surprised by the result of back navigations. As a result, this will almost certainly reduce compatibility in the short run, but it is not certain how much of that will be visible to either users or developers.


On the other hand, there is a cost to having useless back/forward entries and requiring users to repeatedly navigate back to return to the desired content, so it seems like it's worth experimenting to see if we can find a useful behavior to standardize on.



--
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+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.

Chris Harrelson

unread,
Apr 12, 2018, 2:16:17 PM4/12/18
to Nate Chapin, Yutaka Hirano, Yoav Weiss, blink-dev
LGTM2, but please do come back to this thread if you find any legitimate use cases that might be broken. We should also be ready to revert this if there are compat issues.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

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

--
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/CACf%3D2L%2BEcvBm2Rxt%3DbxXfx6Yo__%3DvB%2BgxfvN%2B0TwCvERDr04mg%40mail.gmail.com.

PhistucK

unread,
Apr 12, 2018, 4:41:39 PM4/12/18
to Chris Harrelson, Nate Chapin, Yutaka Hirano, Yoav Weiss, blink-dev
Will the following use case still be supported?
On page A, the user clicks on a link, the application uses history.pushState(...) and navigates to page B. On page B, the user clicks on a link, the application uses history.pushState(...) and navigates to page C. On page C, The user clicks on the back button of the browser. The application has some logic to prevent the navigation due to an unbeforeunload-type of dialog, by re-navigating forward. Clicking on the back button of the browser may either close the dialog, or do nothing (navigation again prevented), according to the application logic. The user reverts their changes and the application logic no longer prevents the navigation and the user clicks on the back button of the browser. Will it skip an entry (go to page A)?

In other words, can a user gesture manipulate the history stack twice (back button and application navigation) if they happen within the user gesture time limit (one second, if I remember correctly)?


PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_%2BxqBouQs9HOVkFkzDSXfyVjD0GB3uF_4qAi%3DmT8YUjw%40mail.gmail.com.

dan...@google.com

unread,
Apr 12, 2018, 7:36:31 PM4/12/18
to blink-dev, chri...@chromium.org, jap...@chromium.org, yhi...@google.com, yo...@yoav.ws
Another edge use case: Chrome and Firefox on iOS actually both use a sequence of pushState calls to restore history into a crashed web view. Hypothetically, if this intervention becomes standard and Apple also ships it, Chrome and Firefox on iOS would be broken. Granted this is all to work around limitations in WKWebView API, but it doesn't seem a complete ridiculous use case for History API.

Nate Chapin

unread,
Apr 13, 2018, 2:31:45 PM4/13/18
to PhistucK, Chris Harrelson, Yutaka Hirano, Yoav Weiss, blink-dev
Once a user gesture has been directed at the document (e.g., by clicking a link), that document may add as many entries to history as it wishes. So in the example you provided, there should not be any behavior change.
~Nate

Nate Chapin

unread,
Apr 13, 2018, 2:36:32 PM4/13/18
to Danyao Wang, blink-dev, Chris Harrelson, Yutaka Hirano, Yoav Weiss
Interesting. Could you point me at the source for where Chrome-on-iOS does this?
~Nate

Danyao Wang

unread,
Apr 13, 2018, 2:48:18 PM4/13/18
to Nate Chapin, blink-dev, Chris Harrelson, Yutaka Hirano, Yoav Weiss
WKBasedNavigatiomManagerImpl::Restore() is the entry point:

wk_navigation_util::CreateRestoreSessionUrl() creates a URL that encodes NavigationItem info in a URL param:

The History API is used here:

Rick Byers

unread,
May 4, 2018, 12:19:20 PM5/4/18
to Danyao Wang, Nate Chapin, blink-dev, Chris Harrelson, Yutaka Hirano, Yoav Weiss
Sorry for the silence on this thread - I had an AI to follow up from an API owners meeting a week ago and am just getting to that now :-(

Regarding Danyao's use case, a similar compat risk in Chrome's other platforms is with extensions.  There could be extensions injecting history entries to pages that wouldn't otherwise meet the criteria. To me the right solution is that such injected script should not be considered "content initiated" - i.e. in chrome we should only consider it "content" when it's in the main world, extension scripts in their own isolated world should be thought of as non-content.  Similarly, as Danyao says, we should try to help ensure that an implementation in Safari would preserve some mechanism for browsers like Chrome for iOS to be treated as non-content (which is already one aspect of a larger problem we have with Chrome on iOS - eg. browser-injected script interfering with page-supplied content security policy).

In the API owners meeting we brainstormed a bit about potential sources of compat risk here.  We're particularly worried about breaking assumptions of pages using the history API (back/forward etc.).  Eg. is it possible there's some site which redirects to an authentication page which sets a cookie and then invokes history.back()? If so this change would totally break such a site (navigating back to the page before), right?  In addition to compat risk, this also seems like a bit of a potential platform rationality issue - having heuristics like the 5 second rule built into the visible behavior of APIs seems pretty bad (although history is already so hard to reason about maybe it's only slightly worse in practice?).

Any chance it would make sense to think of this feature as modifying the behavior of the back button to skip over some entries marked as non-user-initiated, while leaving the programmatic behavior the same and heuristic-free?

Or if you believe having these heuristics directly in the API is the better design, perhaps there are things we could do with UMA/UKM to better measure the compat risk?  For example, can we mark history entries as "to be removed", and then track how often a user navigates back to one of these entries and actually interacts with the page?  With UKM we could get some URLs to try to find specific examples.  From a compat perspective if we found even 0.0001% of page views were badly broken by this change (eg. the scenario I describe above), that would be cause for concern.  So it seems worthwhile to me to try to search for such a needle in the haystack of bad history behavior.  That said, I could be convinced that the best way to do this search is via finch trials or just beta channel and bug reports (as I've argued in other cases where we couldn't find any practical way to measure programatically).

Rick


--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

Ashley Gullen

unread,
May 4, 2018, 6:25:23 PM5/4/18
to Rick Byers, Danyao Wang, Nate Chapin, blink-dev, Chris Harrelson, Yutaka Hirano, Yoav Weiss
Our PWA Construct 3 (editor.construct.net) uses the history API to navigate dialogs. When a dialog opens, we pushState() so the back button can be used to close the dialog. Repeatedly pressing back will close the dialogs from top to bottom, providing a natural way to cancel dialogs on mobile. We implemented this feature because users expected it. The default behavior is to navigate backwards, closing the entire app, and possibly losing the user's unsaved work if the beforeunload handler doesn't stop them - a risky consequence for a common action.

Dialogs are not always opened in user gestures. In general a complex productivity app can open dialogs at any time for any reason. Additionally the prevalence of asynchronous APIs is in general a bad match for user gesture requirements. For example if the app does some async work in response to a user input, then shows a dialog to display the result, then the dialog appears outside of a user gesture so it can't do anything restricted to a user gesture, even if it could have done so only a moment ago. (More web APIs are sensibly becoming async, but this makes the problem worse.) I think that if you limit history entries to user gestures, you will break our PWA's "back to close dialog" feature, without any reasonable workaround.

What we really want in this case anyway is just a "on back button pressed" event. Using the history API for this purpose is so contrived that it involves a couple hundred lines of code and we ran in to a couple of browser bugs hacking it together. (Try making history API calls between back() and onpopstate; nothing seems to work right, so you have to build a queuing system.) I'd love to get rid of it. If you add an "on back button pressed" event I'd happily delete all our history API code and use that instead. I suppose there's then scope to manage when web content is allowed to call preventDefault(). For example blocking that before the user has interacted with the page would be entirely reasonable to prevent abuse. After several clicks it could even do something like show a notification to the user and offer to stop the page overriding the back button.

Ashley


To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Nate Chapin

unread,
May 8, 2018, 6:17:16 PM5/8/18
to Rick Byers, Danyao Wang, blink-dev, Chris Harrelson, Yutaka Hirano, Yoav Weiss
I'm absolutely sympathetic to the concern about the 5 second rule, though I think history behavior already has a bunch of gotchas around timing (e.g.,onload is not of primary importance in modern web development given how poorly it maps to user-visible milestones like interactivity, but the completion of onload is one of the criteria we use in deciding replace vs. append for history entries).

In terms of this modifying only the back button, instead of developer-visible APIs: I think it's a tradeoff of timing-based unpredictability vs. the confusion of history.back() and UI-back-button doing different things. I think, if changing history.back() doesn't cause too much of a compat/predictability problem, it's better to leave the different history navigation methods with identical behavior.  But if there are serious compat problems, I'm willing to make this back button only.

On metrics: Tracking history entries as "to be removed" or tracking provisional navigations as "replacing only because of lack of a user gesture" is hypothetically possible, but would be fairly invasive in terms of the number of layers through which the state would need to be plumbed/stored in order to extract meaningful metrics. The main difficult here is one of timing: we make the decision as to whether the navigation should create a new history entry at the point where the navigation is requested, but we don't use it until the navigation is committed.  At commit time, we're setting state related to the new history entry, not modifying the state of the history entry we're navigating away from.  And even if we did have the requisite state to identify when the user navigated back to a history entry that this intervention would have removed, would there be a straightforward way to identify that the user subsequently navigated back again shortly thereafter? (i.e., the case that would indicate that this intervention would have removed a history entry the user didn't want)

tl;dr: If it were only up to me, I'd default to launching to dev/beta and seeing what sort of bug reports we get.  But if there's something I'm missing in terms of viable metrics, I'm willing to consider it.
~Nate

Ojan Vafai

unread,
May 8, 2018, 7:00:30 PM5/8/18
to Nate Chapin, Rick Byers, dan...@chromium.org, blink-dev, Chris Harrelson, Yutaka Hirano, Yoav Weiss
For the reasons that Nate mentioned, my preferred plan of action is that we try shipping this as is and consider falling back to splitting the UI and the history.back behavior only if we run into real problems in the wild.

Note: I'm recusing myself as a formal API owner on this issue since I was involved in the design of this solution.

Rick Byers

unread,
May 10, 2018, 1:19:53 PM5/10/18
to Ojan Vafai, Domenic Denicola, Nate Chapin, Danyao, blink-dev, Chris Harrelson, Yutaka Hirano, Yoav Weiss
Thank you for your input on this Ashley!  I agree that class of app behavior is exactly the sort of thing we want to avoid breaking here (and we definitely don't want to make it any harder for developers to reason about history, when it already can be quite frustrating).  I think there's one misunderstanding though - the design Nate has described will suppress creating the history entry only when "the user has never interacted with the Document requesting the navigation", not for any navigation that occurs outside the scope of a user gesture as you describe.  In fact, we agree with you that it's increasingly difficult to reason about anything "being triggered by user activation" (i.e. within the scope of a user gesture) and so we're in the process of trying generally to move to a more relaxed model of "has ever had a user gesture".

So, do you also envision scenarios in your application where a dialog is created in a page without the user having interacted with the page at all?  What do you feel the user expectation would be for 'back' when that happens within 5 seconds of page load?  Can you try out your application with chrome://flags/#enable-history-entry-requires-user-gesture enabled to confirm whether you do see a reduced user experience in practice or not?  Nate, I assume M66 already had the behavior you want to ship now (I don't see any recent commits on this bug), right?  I think if we had even a single example of a real-world website that was significantly broken with this flag enabled, we'd want to take that pretty seriously.

Nate/Ojan, if you feel the best way to get data on the compat risk is to just enable the flag, then we'd definitely encourage you to enable the flag in canary/dev channel (via either finch, or a release-block-beta bug tracking turning the flag back off before beta).  No approval is necessary to try such experiments in canary/dev, and certainly we've found such trials to be valuable in the past.

On Tue, May 8, 2018 at 7:00 PM, Ojan Vafai <oj...@chromium.org> wrote:
For the reasons that Nate mentioned, my preferred plan of action is that we try shipping this as is and consider falling back to splitting the UI and the history.back behavior only if we run into real problems in the wild.

Note: I'm recusing myself as a formal API owner on this issue since I was involved in the design of this solution.

On Tue, May 8, 2018 at 3:17 PM Nate Chapin <jap...@chromium.org> wrote:
I'm absolutely sympathetic to the concern about the 5 second rule, though I think history behavior already has a bunch of gotchas around timing (e.g.,onload is not of primary importance in modern web development given how poorly it maps to user-visible milestones like interactivity, but the completion of onload is one of the criteria we use in deciding replace vs. append for history entries).

In terms of this modifying only the back button, instead of developer-visible APIs: I think it's a tradeoff of timing-based unpredictability vs. the confusion of history.back() and UI-back-button doing different things. I think, if changing history.back() doesn't cause too much of a compat/predictability problem, it's better to leave the different history navigation methods with identical behavior.  But if there are serious compat problems, I'm willing to make this back button only.

Hmm, yeah I see the tension here.  In the long run, could you see us wanting to specify the 5s heuristic?  +Domenic@ any thoughts on which approach seems better from the HTML spec and interop perspective?

On metrics: Tracking history entries as "to be removed" or tracking provisional navigations as "replacing only because of lack of a user gesture" is hypothetically possible, but would be fairly invasive in terms of the number of layers through which the state would need to be plumbed/stored in order to extract meaningful metrics. The main difficult here is one of timing: we make the decision as to whether the navigation should create a new history entry at the point where the navigation is requested, but we don't use it until the navigation is committed.  At commit time, we're setting state related to the new history entry, not modifying the state of the history entry we're navigating away from.  And even if we did have the requisite state to identify when the user navigated back to a history entry that this intervention would have removed, would there be a straightforward way to identify that the user subsequently navigated back again shortly thereafter? (i.e., the case that would indicate that this intervention would have removed a history entry the user didn't want)

tl;dr: If it were only up to me, I'd default to launching to dev/beta and seeing what sort of bug reports we get.  But if there's something I'm missing in terms of viable metrics, I'm willing to consider it.

Thanks Nate.  If that would take a lot of work to measure, then I agree it may not be worth it.  We can certainly try an experiment in dev (possibly even a finch trial in beta) to see if we can learn anything from that.

But what do you think about the larger design principle: do we really want heuristics should such heurist
 

Ashley Gullen

unread,
May 12, 2018, 8:18:07 AM5/12/18
to Rick Byers, Ojan Vafai, Domenic Denicola, Nate Chapin, Danyao, blink-dev, Chris Harrelson, Yutaka Hirano, Yoav Weiss
Ah, so it's more like "first user gesture unblocks history API"? I think this could still break our app. One edge case is our app can show a dialog on startup. In this case the dialog will appear without a user gesture and call pushState. When the user presses OK, the dialog will call history.back() to remove the history entry it added. It sounds like if the pushState() silently fails to add a history entry, but the back() call works because it's in a user gesture to press OK, then the result will be the visitor navigates backwards and quits the app. If the app shows a dialog on startup every time, then this might actually make it impossible to use the app.

If we can identify that pushState failed, we can code our way around it, but it would still be backwards incompatible on the wider web. Perhaps the browser could instead queue all history entries added instead of replacing them, and then apply them all in the first user gesture, so subsequent back() calls work as expected. It could apply a limited number, e.g. up to 5 entries, to prevent abuse on page load.  (Our app might need more than 1 queued entry for nested dialogs.)

If the browser's actual back button always navigated back within the 5 second limit, but history.back() calls worked normally, I think that would be reasonable and avoid breaking our app too. It reminds me of music players, which the "previous track" button skips to the beginning of the current track if it's several seconds in, otherwise near the start it actually goes back a track.

Ashley


To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Rick Byers

unread,
May 14, 2018, 9:59:32 AM5/14/18
to Ashley Gullen, Ojan Vafai, Domenic Denicola, Nate Chapin, Danyao, blink-dev, Chris Harrelson, Yutaka Hirano, Yoav Weiss
Thanks Ashley, that's exactly the kind of scenario I was worried about - and the motivation for my argument about restricting our 5-second heuristic to the back button, not the APIs.  Is it possible to actually try your app with the flag enabled to confirm that it would hit issues like this?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Rick Byers

unread,
May 14, 2018, 10:15:09 AM5/14/18
to Ashley Gullen, Ojan Vafai, Domenic Denicola, Nate Chapin, Danyao, blink-dev, Chris Harrelson, Yutaka Hirano, Yoav Weiss
And to be clear, yes of course we could come up with some fix for you.  But my concern is that if we have one concrete example of an app broken by this change just based on pre-ship discussion, there are likely hundreds more out there - and it's that web compat risk (and increasing developer frustration with any already very frustrating area of browser behavior) that worries me here.  If we can't reasonably get hard measurements on how often this could be a problem, but we have one real-wold anecdote doing something that doesn't seem crazy, then I think we have to assume it could be common enough to prevent shipping.

Ashley Gullen

unread,
May 14, 2018, 11:06:58 AM5/14/18
to Rick Byers, Ojan Vafai, Domenic Denicola, Nate Chapin, Danyao, blink-dev, Chris Harrelson, Yutaka Hirano, Yoav Weiss
I tried this in our PWA with #enable-history-entry-requires-user-gesture enabled. I had to make some tweaks, e.g. to guarantee that a dialog appeared on startup. Initially I could not reproduce any issues, but I realised the only reason it worked was we had a hack that postponed a call to history.back() due to the aforementioned API weirdness with making calls at certain times. If I removed the hack and enabled the call to history.back() immediately, it was indeed broken just like I described: when the app starts, closing the dialog navigates backwards and exits the app, making it impossible to get past the dialog if it appears every time. This does not happen when #enable-history-entry-requires-user-gesture is turned off. I believe this is sufficient evidence that it's a breaking change for real-world apps.


To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Aleks Totic

unread,
May 14, 2018, 2:01:56 PM5/14/18
to Rick Byers, ash...@scirra.com, oj...@chromium.org, Domenic Denicola, jap...@chromium.org, dan...@chromium.org, blink-dev, Chris Harrelson, yhi...@google.com, Yoav Weiss
"Back button only intervention" would still break Ashley's site, because it depends on back button for navigation.

"Back button only intervention" breaks* fewer things: 
- history JS API remains predictable.
- on desktop, user can right-click on back button for full history as a workaround.

Both types of intervention break back button behavior on mobile without a workaround.

Aleks

* by break, I mean "some sites with valid use cases might break". It also fixes back button abuse by many sites.

Rick Byers

unread,
May 14, 2018, 2:23:43 PM5/14/18
to Aleks Totic, Ashley Gullen, Ojan Vafai, Domenic Denicola, Nate Chapin, Danyao, blink-dev, Chris Harrelson, Yutaka Hirano, Yoav Weiss
On Mon, May 14, 2018 at 2:01 PM Aleks Totic <ato...@google.com> wrote:
"Back button only intervention" would still break Ashley's site, because it depends on back button for navigation.

I didn't think that was true.  In the scenario Ashley described, it was the page calling "history.back()" when the dialog's close button was clicked that was the problem.  If the user hits the back button they'd go back to before the page was loaded at all, instead of just to a state before the dialog was opened - but that's arguably what the user expected anyway when the dialog was opened on load due to no action of theirs.

Ashley Gullen

unread,
May 15, 2018, 7:58:54 AM5/15/18
to Rick Byers, Aleks Totic, Ojan Vafai, Domenic Denicola, Nate Chapin, Danyao, blink-dev, Chris Harrelson, Yutaka Hirano, Yoav Weiss
Rick is right - in the case I described it is a call to history.back() when the user does something like press OK on a dialog. They aren't using the back button in the browser/OS; they're interacting with the web page normally, but the consequence is an unintended back navigation.

If the user did press the browser/OS back button when a dialog appears before any user interaction, I think it is reasonable to navigate backwards and it is probably what the user expects. However once they have interacted with the page, they will likely expect the browser/OS back button to navigate dialogs as described.

Ashley


To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.

Aleks Totic

unread,
May 15, 2018, 1:48:24 PM5/15/18
to blink-dev, Rick Byers, oj...@chromium.org, Domenic Denicola, jap...@chromium.org, Chris Harrelson, Yutaka Hirano, Yoav Weiss, Danyao Wang, Ashley Gullen
 I think "back button only" is a much better solution. 

History API is ancient, and tricky to use properly. I remember building a Polymer router, and spending some quality time dealing with the history edge cases.

"Back button only" fixes user concerns, while mostly not breaking  backward compatibility.

Aleks

Chris Harrelson

unread,
May 15, 2018, 2:47:51 PM5/15/18
to Aleks Totic, blink-dev, Rick Byers, Ojan Vafai, Domenic Denicola, Nate Chapin, Yutaka Hirano, Yoav Weiss, dan...@chromium.org, Ashley Gullen
I agree that these revised proposals sound better. I like the idea of not changing the results of the history API, but sometimes skipping history entries when the user uses the browser-provided back button and the user agent feels that is the best result for the user.

Chris

Nate Chapin

unread,
May 18, 2018, 4:06:36 PM5/18/18
to Chris Harrelson, Aleks Totic, blink-dev, Rick Byers, Ojan Vafai, Domenic Denicola, Yutaka Hirano, Yoav Weiss, Danyao Wang, Ashley Gullen
Thanks for the feedback, everyone. Having now seen a definite example of a broken site, I think I agree that the compat risk is greater than the benefit of keeping the history API and UI-history-navigation logic identical, so I'll explore restricting this behavior to the back button.
~Nate

shiva...@chromium.org

unread,
Dec 19, 2018, 10:39:09 AM12/19/18
to blink-dev, chri...@chromium.org, ato...@google.com, rby...@chromium.org, oj...@chromium.org, dom...@chromium.org, yhi...@google.com, yo...@yoav.ws, dan...@chromium.org, ash...@scirra.com
The github issue that discusses the latest thinking on this (back-button only) is here.
(this is the internal launch bug).
Reply all
Reply to author
Forward
0 new messages