Contact emails
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+...@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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEiW_U2HfLF4L%3DK-cMNtA%2B4O2evnb%3DNc00tdrAYBCfY2mg%40mail.gmail.com.
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
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6GZwSDT9tgsUVBnRviCtB%2BkCrv3SnhRvPwyjyMmVeTqrQ%40mail.gmail.com.
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/CACf%3D2L%2BZ7Oj-veet%2BQ_sQ9JAi6Rt%2B%2Bry7J5AZ3bCYcEFMO6%3DjQ%40mail.gmail.com.
--
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/CACj%3DBEiW_U2HfLF4L%3DK-cMNtA%2B4O2evnb%3DNc00tdrAYBCfY2mg%40mail.gmail.com.
--
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.
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
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.
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.
--
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 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.
--
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/CACj%3DBEiW_U2HfLF4L%3DK-cMNtA%2B4O2evnb%3DNc00tdrAYBCfY2mg%40mail.gmail.com.
--
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.
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/CACf%3D2L%2BZ7Oj-veet%2BQ_sQ9JAi6Rt%2B%2Bry7J5AZ3bCYcEFMO6%3DjQ%40mail.gmail.com.
--
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/CACj%3DBEiW_U2HfLF4L%3DK-cMNtA%2B4O2evnb%3DNc00tdrAYBCfY2mg%40mail.gmail.com.
--
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/CACf%3D2L%2BEcvBm2Rxt%3DbxXfx6Yo__%3DvB%2BgxfvN%2B0TwCvERDr04mg%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
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.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 view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAErabb-dje-6vz9iWpd%3Dz1XLtYG6B6dDvKzM5CuBVg_Qz3QvSg%40mail.gmail.com.
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/CAFUtAY8A7QooSqrxsU%2BoHiojSto%3DKC4A0oy04An2cGBMXH2jBw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACf%3D2LJxLO485bS%2BTPv22HYr%3DcNMq%3DdBXirSddqpn_QC0s5Cnw%40mail.gmail.com.
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.
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.
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/CAFUtAY_JppAwzXWU%2BXYut2JOuVsryB%2BjjuBxHsp11e9W7div6A%40mail.gmail.com.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
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/CAFUtAY9bDw2LFeRy1q_uZsNPCofJ0ArE5wWe30V7aBtbGE-B6A%40mail.gmail.com.
"Back button only intervention" would still break Ashley's site, because it depends on back button for navigation.
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/CAFUtAY_JppAwzXWU%2BXYut2JOuVsryB%2BjjuBxHsp11e9W7div6A%40mail.gmail.com.
--
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.