Intent to Implement and Ship: Initiating main frame navigations consumes a user gesture

[Charles Harrison]

Contact emails

cshar...@chromium.org

Explainer

N/A

Design doc/Spec

N/A, user gestures are not very well specced today.

Summary

After this change, any operation requiring user activation must have an additional user gesture after a main frame navigation is started.

Draft CL: https://chromium-review.googlesource.com/c/chromium/src/+/676656

Note: navigations currently do *not* require a user gesture. This change will just cause them to consume one (such that subsequent actions requiring a gesture are blocked).

Motivation

The core motivation for this change is to help a subsequent effort to intervene on tab-unders [1]. After this change, tab-unders are guaranteed to open a popup *before* navigating the current page, so they are easily classified. This guarantee will help us to be accurate when we intervene, and ensure there are no gaps in the intervention for sites to exploit.

[1]: tab-under is a bit of an ambiguous term. I am using it to mean when a page opens a new tab to the true destination and navigates the original page to some third party content at the same time.

Demo link

See http://cr.kungfoo.net/popups/tab_under/ for an example. This change will block a popup for the “navigate then popup” case.

Risks

Interoperability and Compatibility

Compatibility risk is low/moderate, as it could break existing tab-under use cases. The cases that break here are ones which navigate, and then open a popup (since the user gesture bit is consumed by the navigation). This could happen if the site synchronously initiates a navigation (e.g. via click()), then tries to window.open.

However, most use cases use window.open to open a popup which is synchronous, along with window.location to navigate the page. Since window.location is asynchronous, it will be performed after the popup is opened. We won’t break this case here.

It will be difficult to measure the impact of this change, or issue deprecation warnings beforehand without adding complex measurement infrastructure. I welcome any advice from blink-dev@ members, and I would be OK implementing this via a slow rollout.

Anecdotally, I tried my change on a number of sites with tabunders (e.g. http://popunderjs.com/) and I haven't seen any breakage yet.

In terms of Interop, this is moving away from other browsers, but I think it is a small amount and it has the chance to move the web forward by further restricting tab-unders.

Edge: No signals

Firefox: No signals

Safari: No signals

Web developers: No signals

Ergonomics

N/A

Activation

N/A

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

Yes.

Link to entry on the feature dashboard

Small change

Requesting approval to ship?

Yes

[Mustaq Ahmed]

I have two alternate ideas, wondering what's your thought around those:

- Why not "navigations require user gestures", instead of "navigations consume user gestures"?  With "require" we should be able to block both "navigation then popup" and "popup then navigation" (unlike "consume" which can't block "popup then navigation").

- For tab-under exploiters, is "click() on an <a>" the most common (or the only) way to initiate navigation?  If mostly yes, then can't we possibly make "click() on an <a>" require user gesture?

[Charles Harrison]

On Wed, Sep 27, 2017 at 2:59 PM, Mustaq Ahmed <mus...@chromium.org> wrote:

I have two alternate ideas, wondering what's your thought around those:

- Why not "navigations require user gestures", instead of "navigations consume user gestures"?  With "require" we should be able to block both "navigation then popup" and "popup then navigation" (unlike "consume" which can't block "popup then navigation").

I am afraid this would break way too much web content. Our tentative idea for the subsequent tab under intervention would be to show browser native UI like the popup blocker when a page tries to navigate

 a. Cross origin

 b. Without a user gesture

 c. And previously opened a popup.

Obviously it would be nice for navigation to require a user gesture, but I feel that is a long way away from being possible right now. For instance, it would break all "client side redirect" solutions.

- For tab-under exploiters, is "click() on an <a>" the most common (or the only) way to initiate navigation?  If mostly yes, then can't we possibly make "click() on an <a>" require user gesture?

I think the most common way is to use window.location to trigger the opener navigation. Requiring a user gesture for simulated events like clicks is an interesting idea, but it doesn't solve the immediate problem unless we also consume the gesture (to prevent subsequent popups). 

[bay...@gmail.com]

Will this break sites that attempt to trigger a file download and navigate to a "thanks for downloading" page as a part of the same flow?

[Jochen Eisinger]

can you clarify whether any top-level navigation will consume, or just cross-site navigations?

On Mon, Oct 9, 2017 at 3:30 PM <bay...@gmail.com> wrote:

Will this break sites that attempt to trigger a file download and navigate to a "thanks for downloading" page as a part of the same flow?

--
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/4b0a4db2-4d94-4c9f-b49c-729f1b66de2c%40chromium.org.

[Charles Harrison]

bayden: This shouldn't block the "thanks for downloading pattern", since neither downloading nor navigating requires a user gesture, as far as I know.

mustaq: Would you mind posting your doc with the things that require user gestures in Chrome?

jochen: The original proposal was that any top level navigation will consume. Some notes on this choice:

 - Restricting to cross-site navigations is a false choice, as we don't know if a navigation will be cross-site until it commits. To be effective we need to consume synchronously at nav start.

 - We already consume a gesture at commit time to another document (I'm 99% sure of this, if we don't it's certainly a bug)

 - I'll probably need to make sure that same-document navigations are not affected here.

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/CALjhuifmNW_V6ivY79LRF%2BKQryAp7NxHRQOiZ1TfOWq8S_iG7A%40mail.gmail.com.

[Mustaq Ahmed]

Here is a list of APIs that use UserGestureIndicator:

https://docs.google.com/document/d/1mcxB5J_u370juJhSsmK0XQONG2CIE3mvu827O-Knw_Y/edit?usp=sharing

The list is created through code search, so only lists direct users.  It is possible that downloading relies on some other APIs listed there.  Not sure though, never tested downloading+gesture.

[elaw...@google.com]

> since neither downloading nor navigating requires a user gesture, as far as I know.

I think whether or not there was a gesture feeds into how SafeBrowsing evaluates the download, but more generally, the pattern of navigating the main page while opening a new window to the target download used to be a common pattern for download sites like CNET's Download.com and the Microsoft Download Center. It looks like those particular sites may have moved away from that pattern though.

On Monday, October 9, 2017 at 9:28:01 AM UTC-5, Charles Harrison wrote:

bayden: This shouldn't block the "thanks for downloading pattern", since neither downloading nor navigating requires a user gesture, as far as I know.

mustaq: Would you mind posting your doc with the things that require user gestures in Chrome?

jochen: The original proposal was that any top level navigation will consume. Some notes on this choice:

 - Restricting to cross-site navigations is a false choice, as we don't know if a navigation will be cross-site until it commits. To be effective we need to consume synchronously at nav start.

 - We already consume a gesture at commit time to another document (I'm 99% sure of this, if we don't it's certainly a bug)

 - I'll probably need to make sure that same-document navigations are not affected here.

On Mon, Oct 9, 2017 at 9:38 AM, Jochen Eisinger <joc...@chromium.org> wrote:

can you clarify whether any top-level navigation will consume, or just cross-site navigations?

On Mon, Oct 9, 2017 at 3:30 PM <bay...@gmail.com> wrote:

Will this break sites that attempt to trigger a file download and navigate to a "thanks for downloading" page as a part of the same flow?

--
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/4b0a4db2-4d94-4c9f-b49c-729f1b66de2c%40chromium.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.

[Charles Harrison]

Thanks Mustaq for the doc. That helpfully frames this intent.

elawrence: Yes a download request has user gesture information sent to safe browsing, if I understand this code correctly. I'm not sure how important that bit is, server side.

Note for the popup case you mention, this specific intent only covers this pattern for a rare edge case, for sites which open the popup *after* they start navigating. I believe this is a smaller minority of sites, as starting a navigation is usually asynchronous, and popup opening with window.open is synchronous.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ef68da37-b7cc-41a9-8dca-ab826ee6c364%40chromium.org.

[Philip Jägenstedt]

For clarity, is this intent now blocked only on LGTMs? Mustaq mentioned "two alternate ideas", and the conclusion isn't entirely clear to me.

Which spec should cover this? Even if it's not spec'd now, there should at least be issues about the lack of a spec, and if at all possible, shared tentative tests for what that spec should eventually require.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADjAqN7vw4J%2Bm%3Dpm7OCiqeVPEwbgOOCWOB4kFz5Dc4oVvDtHCA%40mail.gmail.com.

[Charles Harrison]

Yeah the intent is blocked on LGTMs. I'm also still not sure the best way to ship (e.g. controlled rollout, etc).

Mustaq might have a better spec link, but I think this is the best place. In the spec the user gesture is called the "user activation". I couldn't really find anything about "consuming" the activation.

In terms of tests, I'll try to land some WPT for this change. The general gist would be to simulate a user interaction to navigate, and then after the navigation is initiated, perform some user-gesture requiring action, expecting it to fail.

From the link I sent, it seems like there aren't many features that are specced to require user activation (at this point). It looks like sandboxed top level navigation without user activation is one of them though.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYeUE9BQv%3DL8oHtkdFNgWH02yApvTocJp-jMtpHgNjJO4w%40mail.gmail.com.

[Anne van Kesteren]

On Fri, Oct 13, 2017 at 2:47 PM, Charles Harrison
<cshar...@chromium.org> wrote:
> Mustaq might have a better spec link, but I think this is the best place. In
> the spec the user gesture is called the "user activation". I couldn't really
> find anything about "consuming" the activation.

That's because that concept doesn't exist. If it needs to exist, it
would be good to start a discussion about it over at
https://github.com/whatwg/html/issues/new.

> From the link I sent, it seems like there aren't many features that are
> specced to require user activation (at this point). It looks like sandboxed
> top level navigation without user activation is one of them though.

There's other standards that tie into the concept, such as Fullscreen.
Unfortunately we don't have a system yet where you can easily find all
users of a given definition. It only works within a single standard.


--
https://annevankesteren.nl/

[Charles Harrison]

I just looked through some open issues and this problem is referenced here by rbyers. It seems that Gecko does *not* have a parallel concept of consuming gestures, and e.g. calling window.open() twice in response to a click will open two popups. I tested this on Safari too and it opened two popups as well. Maybe Chrome is alone in this behavior?

In any case, I can definitely file an issue to start the conversation on speccing this.

[Anne van Kesteren]

On Fri, Oct 13, 2017 at 4:17 PM, Charles Harrison
<cshar...@chromium.org> wrote:
> I just looked through some open issues and this problem is referenced here
> by rbyers. It seems that Gecko does *not* have a parallel concept of
> consuming gestures, and e.g. calling window.open() twice in response to a
> click will open two popups. I tested this on Safari too and it opened two
> popups as well. Maybe Chrome is alone in this behavior?
>
> In any case, I can definitely file an issue to start the conversation on
> speccing this.

I think that would be great. That issue is rather generic so it
probably makes sense to split it up a bit.


--
https://annevankesteren.nl/

[Mustaq Ahmed]

I agree with Anne that the issue seems generic.  But IMHO the core problem here is that the concept is still too vague, forcing each browser to implement it in an isolated manner.  Here is a case study for popups, which shows that "consuming or not" is only one part of the problem.

From that perspective, I think the existing whatwg issue Charles mentioned above is still the right place to discuss it.  We can always fork the discussion later once we know a right/acceptable model.

+Domenic for his comments.

[Chris Harrelson]

I see that there is now an Intent to Implement (from Mustaq) that sounds like it has the purpose of specifying the meaning of the underlying concepts of this intent.

Unfortunately, it seems that still doesn't leave this intent in a great state w.r.t. standardization, unless we're willing to block it on Mustaq's work.

Also this intent has a somewhat unknown amount of effect on existing web content (including explicit concerns on this thread from developers about compatibility), which to me is more reason to spend time trying to start the process of specification. It would be bad to put developers through a lot of compatibility pain and then have to do it again later once we learn more.

If there were spec language that covered the use-cases of this Intent (eve in draft form), and were felt to be likely forward-compatible by the consensus of whatwg, and we had feedback from developer or site research about their use-cases, that would be good. Is that reasonable?

Chris

--
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/CAB0cuO6bnawBTKxW863qCRsf36mbCBWQyp37NX514-KOypW_OQ%40mail.gmail.com.

[Charles Harrison]

Domenic: Sorry, I am Charlie not Chris :) Your new issue looks good. We certainly need to make sure everything affected by user activation changes are documented and browser are aligned. 

I agree that it probably wrong to spec some ad-hoc Chrome consumption behavior, with the fact that Mustaq is working on a more reasoned overhaul of the entire space. This makes me feel like following Chris' advice to draft some spec language *is* probably blocked on at least in some part by Mustaq's intent, since we probably can't be sure what we come up with is forward compatible until the Simple User Activation work moves forward a bit more (i.e. draft language for consuming activation). Given the concerns on the thread, this seems reasonable to me.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_Z4JMPKds7dfbWNipNnjxB8Rf9e0HpQMGdCfQyQt_vjg%40mail.gmail.com.

[Ojan Vafai]

I'm worried that Mustaq's work will take a couple quarters before it's sufficiently stable in the wild that we will have cross-vendor agreement on it. Then, on top of that, we don't even know if the solution in this thread will be sufficiently web compatible without trying shipping it.

If we serialize the work, we may delay shipping this for more than a year. Given the user pain involved in this case, that doesn't seem like the right choice.

We should absolutely continue Mustaq's work towards a design all browsers will implement. That may in turn mean changing Chrome behavior twice.

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/CAB0cuO6bnawBTKxW863qCRsf36mbCBWQyp37NX514-KOypW_OQ%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/CAOMQ%2Bw_Z4JMPKds7dfbWNipNnjxB8Rf9e0HpQMGdCfQyQt_vjg%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/CADjAqN4NcwUzOkYvEFWpu_qwiV-9CzVxR98S_XztruAn%2BaE6fw%40mail.gmail.com.

[Jochen Eisinger]

I'm not sure whether we'll get to a point where consumption is spec'd in a cross browser fashion. Chromium introduced consumption to avoid spawning more than one process at a time (which isn't an issue for other browsers depending on their process management), and chromium also allows for per-site popup blocking rules which makes it possible for users to work around potential breakages (again something that not all browsers offer).

[Philip Jägenstedt]

If spec'ing this reasonably depends on Mustaq's work, then I agree that it can't be blocked on that.

Even if the detailed spec prose is unknown at this point, how feasible would it be to write tests for the things that definitely should or shouldn't work, to constrain the shape of the eventual solution? Such tentative tests could persist until this is ripe for writing text prose.

I think the main risk that other vendors eventually say that they have no reason to have a consuming behavior at all. Is that likely? Since this issue is motivated in part by tab-unders, it seems like all browsers should have some motivation to address it, it's not all about Chrome-specific concerns like number of processes.

[Charles Harrison]

Philip: Do you mean tentative tests for this specific proposal, or gesture consumption in general? Writing a tentative tests for this proposal is definitely doable. I think Mustaq can speak to whether or not this is true for his proposal.

Ojan: Yeah it would be too bad to serialize this with Mustaq's work, though we could always implement the fallback option specific to tab-unders if need be, which doesn't require consumption as a concept.

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/CAB0cuO6bnawBTKxW863qCRsf36mbCBWQyp37NX514-KOypW_OQ%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/CAOMQ%2Bw_Z4JMPKds7dfbWNipNnjxB8Rf9e0HpQMGdCfQyQt_vjg%40mail.gmail.com.

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

[Luna Lu]

We should be able to get UseCounter with UKM soon.

Luna Lu | Software Engineer | loon...@google.com | +1 519 513 5751

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADjAqN5ZBbhNKCYvV5UVka5bEVvc6O_c_ADmbirkfuHhybfJiw%40mail.gmail.com.

[Philip Jägenstedt]

On Mon, Oct 16, 2017 at 4:54 PM Charles Harrison <cshar...@chromium.org> wrote:

Philip: Do you mean tentative tests for this specific proposal, or gesture consumption in general? Writing a tentative tests for this proposal is definitely doable. I think Mustaq can speak to whether or not this is true for his proposal.

I meant just for this proposal. For the larger issue, I suppose it might also be tentative tests, or not, depending on the order of things.

[Charles Harrison]

Yeah, I mentioned a tentative test we could write above in one of the earlier emails. A test could start a navigation with a gesture (to e.g. a blackholed endpoint), then attempt to perform an action which requires activation (like fullscreen), expecting it to fail. If the fullscreen request is accompanied by another gesture, it should succeed.

[Mustaq Ahmed]

I agree with everyone here: the user-facing issue Charles is targeting here shouldn't be delayed because of an open-ended spec issue.  Even if we end up not spec-ing the consumption behavior at all, we can still have it as a Chrome-specific behavior as we have done for years with popups.  And two other APIs have started consuming user activation recently.

We should keep discussing the spec challenges in the whatwg issue.

Charles, I am not an expert in navigation so may be I am missing something: to me, the impl difference between navigations requiring user activation w/o consumption vs w/consumption seems trivial.  If this is the case, can we consider comparing the two approaches for the tab-under problem?

Mustaq

[Charles Harrison]

On Mon, Oct 16, 2017 at 12:41 PM, Mustaq Ahmed <mus...@google.com> wrote:

I agree with everyone here: the user-facing issue Charles is targeting here shouldn't be delayed because of an open-ended spec issue.  Even if we end up not spec-ing the consumption behavior at all, we can still have it as a Chrome-specific behavior as we have done for years with popups.  And two other APIs have started consuming user activation recently.

We should keep discussing the spec challenges in the whatwg issue.

Charles, I am not an expert in navigation so may be I am missing something: to me, the impl difference between navigations requiring user activation w/o consumption vs w/consumption seems trivial.  If this is the case, can we consider comparing the two approaches for the tab-under problem?

Sorry I'm not sure I understand. I don't think we could ever launch something that makes navigation require a user gesture any time soon, with or without consumption. This would break things like meta refresh, and client redirects. The choices we have for tab-under blocking are

1. Make navigations consume a gesture (but do not require a gesture for navigation). Aka this intent.

2. Make popup blocking code track user gestures received and implement consumption-like behavior for starting cross-origin navigations (as detailed in the tab-under doc). This is very similar to (1) in practice except it is restricted to popups, and "consumption" only occurs when starting or redirecting to a cross-origin site. We can afford to be a bit more relaxed in this situation imo because the special casing applies only to popups. 

[Mustaq Ahmed]

Didn't mean to include all "types" of navigations, my bad.  I meant to block (all/some) JS APIs that can trigger navigations.  For example, what if "window.location changes require user gestures" (since you mentioned this is the most common trigger for tab-under)?

Just trying to make sure we have considered all options that "require user gestures".  This is because all current APIs that use UGIs require gestures, and yet we have two classes of those APIs: popup like (requires-and-consumes gestures) and fullscreen-like (requires-but-doesn't-consume).  The result of combining different API classes feels hacky already.  Adding a third kind (consumes-w/o-requiring) won't improve the situation.

[Charles Harrison]

Mustaq: thanks for the clarification. We talked about about this offline but I just wanted to summarize my thoughts.

Requiring user gesture on a subset of navigations (e.g. JS ones) is reasonable (and would avoid breaking meta refresh among others), but I still think it isn't possible for two reasons:

 1. My guess is that most tab-under redirects are using the same APIs (e.g. window.location) as regular client-side redirects, so we'd still end up breaking a lot of content.

 2. If we only disallow certain JS apis from navigating without gestures, abusive actors who want to do tab-unders will just move to the allowed APIs which don't do consuming.

In any case, I hear you loud and clear that adding another class of user gesture isn't desirable. I wish we could somehow implement this using one of the existing patterns, and I'll keep thinking about possibilities.

[Domenic Denicola]

(Sorry about the mistaken identities, Charlie!)

 

From my perspective, I would also not block this intent on spec or interop work; it’s specifically designed to prevent abuse and protect users, in an area which has terrible interop already. I guess I did not make that clear in my previous message.

 

It’ll be great if we either come up with a way of using existing patterns while also getting these benefits, or figure out a way that in Mustaq’s proposed world we also get these benefits. I’m happy you’re thinking about that (per your last paragraph). But even if we don’t figure that out, it seems reasonable to me to still ship a quick fix here to benefit our users, at the cost of making a bit more work for ourselves down the line when we do drive toward interop.

 

 

--

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/CADjAqN52oh6744RzMFD-g0g8YrRiwHXjQGsTGmzUaON6X_c%2BGw%40mail.gmail.com.

[Charles Harrison]

Thanks for the clarification Domenic. I'm OK moving forward without blocking on spec work.

In terms of thinking ahead and making the spec work easier, I've done some thinking. The main concern this intent is meant to address is to block popups after a main frame navigation is initiated, without a user gesture in between. This could be achieved in a few ways, which I've detailed with pros/cons.

1. This intent, which additionally blocks access to all other APIs requiring user activation, after a main frame nav is initiatated

Pros:

  a. There are fewer technical challenges

  b. It reduces special-casing in the platform in some sense (e.g. we aren't just tacking on rules to popups)

Cons:

  a. It affects a wider breadth of the platform (any API using user activation), which could lead to more compatibility / interop risk.

  b. It introduces a new concept of APIs which "consume" but don't "require" user activation.

2. Block popups after a main frame navigation is initiated, without a user gesture in between. I.e. implement an ad-hoc consuming special cased just for popups.

 Pros: 

  a. Does not introduce a new "just consume" concept to the platform, though it kind of does in a backhand way

 Cons:

  a. Introduces a new concept of user activation as a point in time, but perhaps this can be mitigated.

  b. Is a bit more complex to implement, requires changes in Chrome's browser process.

  c. Special cases popups in the platform.

3. Block popups from site if any main frame navigation is ongoing.

 Pros:

  a. Simple (afaict, spec experts may have other views)

  b. Does not have anything to do with user activation

 Cons:

  a. Will probably be more difficult to ship. Breaks the use case of initiating a slow navigation, and clicking on a popup-opening link while waiting for the nav to finish.

4. Have some subset of navigation APIs which both consume and require user activation (i.e. Mustaq's idea)

 Pros:

  a. Does not introduce a new "just consume" concept to the platform

 Cons:

  a. Potentially introduces gaps in our tab-under implementation, which could be abused by bad actors

  b. Probably (imo) unshippable due to the "requiring user gesture" part. I'm not confident any navigation API could add that requirement.

  c. Is a bit more complex to implement, requires changes in potentially many places calling into navigation code

If anyone prefers one of these solutions over (1), please let me know.

--

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

[Mustaq Ahmed]

Thanks Charlie, this gives me a pretty good understanding of the alternates.

From user-activation perspective, I would prefer [3] or [4].  To me, [3] seems the best since the only con you mentioned looks like a minor one (again as a layman in navigation details).  If a user does something during a slow navigation, the exact outcome seems hard to define (e.g. the new page may load before the click is fully handled).

For [4], is there a way to route all JS-initiated navigation requests through a common entry-point?  If no, I agree any gaps would be picked up by bad actors.

[Charles Harrison]

On Thu, Oct 19, 2017 at 12:41 PM, Mustaq Ahmed <mus...@google.com> wrote:

Thanks Charlie, this gives me a pretty good understanding of the alternates.

From user-activation perspective, I would prefer [3] or [4].  To me, [3] seems the best since the only con you mentioned looks like a minor one (again as a layman in navigation details).  If a user does something during a slow navigation, the exact outcome seems hard to define (e.g. the new page may load before the click is fully handled).

Yes, [3] is very appealing to me too, and I didn't realize it as an option until I thought about the problem space for a bit. I am nervous given that this will block *all* new windows including target=_blank URLs. My gut is that we won't be able to ship it. It is a much more aggressive (for popups at least) intervention than this intent.

For [4], is there a way to route all JS-initiated navigation requests through a common entry-point?  If no, I agree any gaps would be picked up by bad actors.

I think this might be possible, but I think bad actors will still be able to get around it. What about injecting a meta refresh tag? The navigation itself is not coming from JS:

document.body.onclick = function() {

  var meta = document.createElement("meta");

  meta.httpEquiv = 'refresh';

  // Navigate in .1 seconds, the browser won't know this came from script unless it is really smart!

  meta.content = '.1; url=https://www.evil.com';

  document.body.appendChild(meta);

}

[Anne van Kesteren]

On Tue, Oct 17, 2017 at 7:03 PM, Domenic Denicola <d...@domenic.me> wrote:
> From my perspective, I would also not block this intent on spec or interop
> work; it’s specifically designed to prevent abuse and protect users, in an
> area which has terrible interop already. I guess I did not make that clear
> in my previous message.

How does this intent relate to ongoing work over at
https://github.com/WICG/gesture-delegation? That seems to build
features on top of this kind of model. That seems a little problematic
if we don't yet know whether the model will be successful.


--
https://annevankesteren.nl/

[Domenic Denicola]

From: Anne van Kesteren [mailto:ann...@annevk.nl]

> How does this intent relate to ongoing work over at https://github.com/WICG/gesture-delegation? That seems to build features on top of this kind of model. That seems a little problematic if we don't yet know whether the model will be successful.

I don't think "this intent", for main frame navigations consuming the user gesture, is very related to WICG/gesture-delegation. For example there is no "navigation" token in the proposed DOMTokenList. (Indeed, most of the uses mentioned at https://github.com/whatwg/html/issues/3123 do not appear in the token list. I filed https://github.com/WICG/gesture-delegation/issues/10.) Instead both are related to ongoing work on achieving interop on user activation.

That said, I agree with your assessment that WICG/gesture-delegation builds on top of a speculative architecture and it's not clear it would make sense to ship in other browsers. I trust the API Owners to make the right call when the intent to ship comes through about whether such a feature is destined to be part of the interoperable web, and as such is OK to ship in Chrome.

[Mustaq Ahmed]

FYI for Charlie: looks like we already have a navigation code that relies "somewhat" on user activation.  "Somewhat" because it doesn't rely on a currently active user gesture, I suspect because of the challenges you mentioned earlier.

https://bugs.chromium.org/p/chromium/issues/detail?id=776508#c2

[Charles Harrison]

Yeah I responded on the bug but this is one of the reasons why I was hesitant that we could ship anything that makes navigation require a user gesture. We couldn't even do it without loosening it to "sticky" user gesture for cross origin frames navigating the parent.

[Rick Byers]

We discussed this intent in the API owners meeting today (owners present: chrishtr, jochen, mkwst, rbyers).  I think there was rough consensus on a few points:

There's support for this general idea. Continuing to try to reduce user annoyance (tab unders, etc.) despite likely causing some compat pain is important to our mission.  The idea of consuming any active user gesture on navigation makes a lot of sense to me.  I wouldn't generally expect the page to be doing anything user-centric after it's started to navigate away (just cleanup, persist state, etc.).  Maybe it would even make sense to go further and say that a page that has started to navigate away is no longer capable of receiving user activation at all.  It's basically a race at this point if the user interacts again during unload - right?

Chrome's pop-up blocking behavior is unique (being the only browser to block multiple pop-ups, etc.). It seems quite unlikely that we'd have success anytime soon getting "consumption" behavior into the HTML spec (since no other engine is interested in this), yet also very unlikely that we'd be willing to remove the behavior from Chrome. If possible we should try to separate all the good work to fully standardize "user activation" from some of this messier stuff that's (nearly) specific to pop-ups. It would be shame to let our long-history of non-standard pop-up blocking behavior stall/delay progress in the work to improve interop for the wide variety of features relying on simple "activation".  If we can get all the other cases fully spec'd and on a path to full interop, that'll be a fantastic improvement (even if Chrome's pop-up blocking is still totally non-standard).  Some of us are still hopeful that we can eventually achieve interop and full standardization around pop-ups, but concede that it shouldn't be the highest priority. Anne / Domenic, could you live with some pragmatic middle ground like this for now?

Regardless of debates around standardization, we have a responsibility to web developers to clearly explain how our pop-up blocker behaves and how that behavior is changing.  So if we're not going to try to write a spec to cover 'consumption' or the changes we're talking about here, we'd like to at least see some permanent documentation page somewhere that can evolve over time (example code / tests would be awesome too). We'll link to this page from the deprecations/removals blog post for the milestone a change goes active in and ideally from a console warning on blocked popups.  Charlie, since you're working on a series of changes here, what do you think about trying to write something (eg. on chromium.org) attempting to describe our pop-up blocking behavior?

I can understand how the compat risk is very difficult to quantify, but my intuition aligns with yours that it seems like it shouldn't be likely to a big problem. I support experimenting with this well before branch.  Eg. you could land this behavior now for M64 canary/dev channel with a RBB-64 bug assigned to yourself to revert/disable before branch and then we could discuss what, if any, site compat bugs were found. If we can't find any concrete case that is broken, then building some complex tracking infrastructure to try to quantify the usage would almost certainly be a waste of time (especially since even a moderate usage could be explained primarily by existing abuse).

So, for me, if we could reasonably detangle these consumption cases from the ongoing "user activation" work (allowing Mustaq to focus on the more tractable and broadly impactful subset), and get some decent developer documentation published on our special pop-up blocking behavior, then that would be enough for me to be comfortable shipping this proposal.

--
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/CADjAqN7hsj8XppFjoqNVJoPTDhJ_xXaSU33vCxnyKaR_3bAMKw%40mail.gmail.com.

[Charles Harrison]

Thanks Rick! I left some comments inline.

On Thu, Oct 26, 2017 at 3:07 PM, Rick Byers <rby...@chromium.org> wrote:

We discussed this intent in the API owners meeting today (owners present: chrishtr, jochen, mkwst, rbyers).  I think there was rough consensus on a few points:

There's support for this general idea. Continuing to try to reduce user annoyance (tab unders, etc.) despite likely causing some compat pain is important to our mission.  The idea of consuming any active user gesture on navigation makes a lot of sense to me.  I wouldn't generally expect the page to be doing anything user-centric after it's started to navigate away (just cleanup, persist state, etc.).  Maybe it would even make sense to go further and say that a page that has started to navigate away is no longer capable of receiving user activation at all.  It's basically a race at this point if the user interacts again during unload - right?

Yep this would be a race, but it's a race the user generally will win if the navigation is slow. I'm not confident, but I feel like applying this extra restriction would be overly confusing for users and developers, and I don't really see us gaining anything from it.

 

Chrome's pop-up blocking behavior is unique (being the only browser to block multiple pop-ups, etc.). It seems quite unlikely that we'd have success anytime soon getting "consumption" behavior into the HTML spec (since no other engine is interested in this), yet also very unlikely that we'd be willing to remove the behavior from Chrome. If possible we should try to separate all the good work to fully standardize "user activation" from some of this messier stuff that's (nearly) specific to pop-ups. It would be shame to let our long-history of non-standard pop-up blocking behavior stall/delay progress in the work to improve interop for the wide variety of features relying on simple "activation".  If we can get all the other cases fully spec'd and on a path to full interop, that'll be a fantastic improvement (even if Chrome's pop-up blocking is still totally non-standard).  Some of us are still hopeful that we can eventually achieve interop and full standardization around pop-ups, but concede that it shouldn't be the highest priority. Anne / Domenic, could you live with some pragmatic middle ground like this for now?

Regardless of debates around standardization, we have a responsibility to web developers to clearly explain how our pop-up blocker behaves and how that behavior is changing.  So if we're not going to try to write a spec to cover 'consumption' or the changes we're talking about here, we'd like to at least see some permanent documentation page somewhere that can evolve over time (example code / tests would be awesome too). We'll link to this page from the deprecations/removals blog post for the milestone a change goes active in and ideally from a console warning on blocked popups.  Charlie, since you're working on a series of changes here, what do you think about trying to write something (eg. on chromium.org) attempting to describe our pop-up blocking behavior?

Yes, I will happily help write some documentation. Would it be OK to write (web-dev focused) markdown that is in the source tree? I think that'd be easiest to maintain and increases visibility to Chromium devs. We could link to it from chromium.org.

 

I can understand how the compat risk is very difficult to quantify, but my intuition aligns with yours that it seems like it shouldn't be likely to a big problem. I support experimenting with this well before branch.  Eg. you could land this behavior now for M64 canary/dev channel with a RBB-64 bug assigned to yourself to revert/disable before branch and then we could discuss what, if any, site compat bugs were found. If we can't find any concrete case that is broken, then building some complex tracking infrastructure to try to quantify the usage would almost certainly be a waste of time (especially since even a moderate usage could be explained primarily by existing abuse).

Let me look over the overhead to launching it behind a feature flag (enabled by default), which will let us be a bit more flexible. There are some metrics we can look at for how much we are affecting popups.

[Rick Byers]

On Thu, Oct 26, 2017 at 3:56 PM, Charles Harrison <cshar...@chromium.org> wrote:

Thanks Rick! I left some comments inline.

On Thu, Oct 26, 2017 at 3:07 PM, Rick Byers <rby...@chromium.org> wrote:

We discussed this intent in the API owners meeting today (owners present: chrishtr, jochen, mkwst, rbyers).  I think there was rough consensus on a few points:

There's support for this general idea. Continuing to try to reduce user annoyance (tab unders, etc.) despite likely causing some compat pain is important to our mission.  The idea of consuming any active user gesture on navigation makes a lot of sense to me.  I wouldn't generally expect the page to be doing anything user-centric after it's started to navigate away (just cleanup, persist state, etc.).  Maybe it would even make sense to go further and say that a page that has started to navigate away is no longer capable of receiving user activation at all.  It's basically a race at this point if the user interacts again during unload - right?

Yep this would be a race, but it's a race the user generally will win if the navigation is slow. I'm not confident, but I feel like applying this extra restriction would be overly confusing for users and developers, and I don't really see us gaining anything from it.

Sounds good. I wasn't actually saying I preferred the additional restriction - just that conceptually I don't see obvious value in supporting any activation-triggered behavior after navigation has started.

Chrome's pop-up blocking behavior is unique (being the only browser to block multiple pop-ups, etc.). It seems quite unlikely that we'd have success anytime soon getting "consumption" behavior into the HTML spec (since no other engine is interested in this), yet also very unlikely that we'd be willing to remove the behavior from Chrome. If possible we should try to separate all the good work to fully standardize "user activation" from some of this messier stuff that's (nearly) specific to pop-ups. It would be shame to let our long-history of non-standard pop-up blocking behavior stall/delay progress in the work to improve interop for the wide variety of features relying on simple "activation".  If we can get all the other cases fully spec'd and on a path to full interop, that'll be a fantastic improvement (even if Chrome's pop-up blocking is still totally non-standard).  Some of us are still hopeful that we can eventually achieve interop and full standardization around pop-ups, but concede that it shouldn't be the highest priority. Anne / Domenic, could you live with some pragmatic middle ground like this for now?

Regardless of debates around standardization, we have a responsibility to web developers to clearly explain how our pop-up blocker behaves and how that behavior is changing.  So if we're not going to try to write a spec to cover 'consumption' or the changes we're talking about here, we'd like to at least see some permanent documentation page somewhere that can evolve over time (example code / tests would be awesome too). We'll link to this page from the deprecations/removals blog post for the milestone a change goes active in and ideally from a console warning on blocked popups.  Charlie, since you're working on a series of changes here, what do you think about trying to write something (eg. on chromium.org) attempting to describe our pop-up blocking behavior?

Yes, I will happily help write some documentation. Would it be OK to write (web-dev focused) markdown that is in the source tree? I think that'd be easiest to maintain and increases visibility to Chromium devs. We could link to it from chromium.org.

Great, thanks!  That's fine with me, as long as it's approachable for web-devs (eg. not too much implementation detail, or at least those details kept to a separate section). 

I can understand how the compat risk is very difficult to quantify, but my intuition aligns with yours that it seems like it shouldn't be likely to a big problem. I support experimenting with this well before branch.  Eg. you could land this behavior now for M64 canary/dev channel with a RBB-64 bug assigned to yourself to revert/disable before branch and then we could discuss what, if any, site compat bugs were found. If we can't find any concrete case that is broken, then building some complex tracking infrastructure to try to quantify the usage would almost certainly be a waste of time (especially since even a moderate usage could be explained primarily by existing abuse).

Let me look over the overhead to launching it behind a feature flag (enabled by default), which will let us be a bit more flexible. There are some metrics we can look at for how much we are affecting popups.

Yeah, that could be interesting for sure. Surely we should be able to measure the change in pop-up blocker "allow" usage, right?  If the allow ratio is significantly higher for users with the change, that would suggest it might not be a good tradeoff...

[Charles Harrison]

On Thu, Oct 26, 2017 at 4:26 PM, Rick Byers <rby...@chromium.org> wrote:

On Thu, Oct 26, 2017 at 3:56 PM, Charles Harrison <cshar...@chromium.org> wrote:

Thanks Rick! I left some comments inline.

On Thu, Oct 26, 2017 at 3:07 PM, Rick Byers <rby...@chromium.org> wrote:

We discussed this intent in the API owners meeting today (owners present: chrishtr, jochen, mkwst, rbyers).  I think there was rough consensus on a few points:

There's support for this general idea. Continuing to try to reduce user annoyance (tab unders, etc.) despite likely causing some compat pain is important to our mission.  The idea of consuming any active user gesture on navigation makes a lot of sense to me.  I wouldn't generally expect the page to be doing anything user-centric after it's started to navigate away (just cleanup, persist state, etc.).  Maybe it would even make sense to go further and say that a page that has started to navigate away is no longer capable of receiving user activation at all.  It's basically a race at this point if the user interacts again during unload - right?

Yep this would be a race, but it's a race the user generally will win if the navigation is slow. I'm not confident, but I feel like applying this extra restriction would be overly confusing for users and developers, and I don't really see us gaining anything from it.

Sounds good. I wasn't actually saying I preferred the additional restriction - just that conceptually I don't see obvious value in supporting any activation-triggered behavior after navigation has started.

Chrome's pop-up blocking behavior is unique (being the only browser to block multiple pop-ups, etc.). It seems quite unlikely that we'd have success anytime soon getting "consumption" behavior into the HTML spec (since no other engine is interested in this), yet also very unlikely that we'd be willing to remove the behavior from Chrome. If possible we should try to separate all the good work to fully standardize "user activation" from some of this messier stuff that's (nearly) specific to pop-ups. It would be shame to let our long-history of non-standard pop-up blocking behavior stall/delay progress in the work to improve interop for the wide variety of features relying on simple "activation".  If we can get all the other cases fully spec'd and on a path to full interop, that'll be a fantastic improvement (even if Chrome's pop-up blocking is still totally non-standard).  Some of us are still hopeful that we can eventually achieve interop and full standardization around pop-ups, but concede that it shouldn't be the highest priority. Anne / Domenic, could you live with some pragmatic middle ground like this for now?

Regardless of debates around standardization, we have a responsibility to web developers to clearly explain how our pop-up blocker behaves and how that behavior is changing.  So if we're not going to try to write a spec to cover 'consumption' or the changes we're talking about here, we'd like to at least see some permanent documentation page somewhere that can evolve over time (example code / tests would be awesome too). We'll link to this page from the deprecations/removals blog post for the milestone a change goes active in and ideally from a console warning on blocked popups.  Charlie, since you're working on a series of changes here, what do you think about trying to write something (eg. on chromium.org) attempting to describe our pop-up blocking behavior?

Yes, I will happily help write some documentation. Would it be OK to write (web-dev focused) markdown that is in the source tree? I think that'd be easiest to maintain and increases visibility to Chromium devs. We could link to it from chromium.org.

Great, thanks!  That's fine with me, as long as it's approachable for web-devs (eg. not too much implementation detail, or at least those details kept to a separate section). 

I can understand how the compat risk is very difficult to quantify, but my intuition aligns with yours that it seems like it shouldn't be likely to a big problem. I support experimenting with this well before branch.  Eg. you could land this behavior now for M64 canary/dev channel with a RBB-64 bug assigned to yourself to revert/disable before branch and then we could discuss what, if any, site compat bugs were found. If we can't find any concrete case that is broken, then building some complex tracking infrastructure to try to quantify the usage would almost certainly be a waste of time (especially since even a moderate usage could be explained primarily by existing abuse).

Let me look over the overhead to launching it behind a feature flag (enabled by default), which will let us be a bit more flexible. There are some metrics we can look at for how much we are affecting popups.

Yeah, that could be interesting for sure. Surely we should be able to measure the change in pop-up blocker "allow" usage, right?  If the allow ratio is significantly higher for users with the change, that would suggest it might not be a good tradeoff...

Yep, the change in the "allow" usage for the popup setting will be useful, as well as the one-off click-through usage.

 

 

So, for me, if we could reasonably detangle these consumption cases from the ongoing "user activation" work (allowing Mustaq to focus on the more tractable and broadly impactful subset), and get some decent developer documentation published on our special pop-up blocking behavior, then that would be enough for me to be comfortable shipping this proposal.

On Wed, Oct 25, 2017 at 2:43 PM, Charles Harrison <cshar...@chromium.org> wrote:

Yeah I responded on the bug but this is one of the reasons why I was hesitant that we could ship anything that makes navigation require a user gesture. We couldn't even do it without loosening it to "sticky" user gesture for cross origin frames navigating the parent.

On Tue, Oct 24, 2017 at 3:20 PM, Mustaq Ahmed <mus...@google.com> wrote:

FYI for Charlie: looks like we already have a navigation code that relies "somewhat" on user activation.  "Somewhat" because it doesn't rely on a currently active user gesture, I suspect because of the challenges you mentioned earlier.

https://bugs.chromium.org/p/chromium/issues/detail?id=776508#c2

On Fri, Oct 20, 2017 at 10:22 AM, Domenic Denicola <d...@domenic.me> wrote:

From: Anne van Kesteren [mailto:ann...@annevk.nl]

> How does this intent relate to ongoing work over at https://github.com/WICG/gesture-delegation? That seems to build features on top of this kind of model. That seems a little problematic if we don't yet know whether the model will be successful.

I don't think "this intent", for main frame navigations consuming the user gesture, is very related to WICG/gesture-delegation. For example there is no "navigation" token in the proposed DOMTokenList. (Indeed, most of the uses mentioned at https://github.com/whatwg/html/issues/3123 do not appear in the token list. I filed https://github.com/WICG/gesture-delegation/issues/10.) Instead both are related to ongoing work on achieving interop on user activation.

That said, I agree with your assessment that WICG/gesture-delegation builds on top of a speculative architecture and it's not clear it would make sense to ship in other browsers. I trust the API Owners to make the right call when the intent to ship comes through about whether such a feature is destined to be part of the interoperable web, and as such is OK to ship in Chrome.

--
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/CADjAqN7hsj8XppFjoqNVJoPTDhJ_xXaSU33vCxnyKaR_3bAMKw%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/CAFUtAY-LGZxS_9hC%2BtusV7evBj5qVxRVfU7qy8-ehZYHMBcMXw%40mail.gmail.com.

[Domenic Denicola]

> Chrome's pop-up blocking behavior is unique (being the only browser to block multiple pop-ups, etc.). It seems quite unlikely that we'd have success anytime soon getting "consumption" behavior into the HTML spec (since no other engine is interested in this), yet also very unlikely that we'd be willing to remove the behavior from Chrome. If possible we should try to separate all the good work to fully standardize "user activation" from some of this messier stuff that's (nearly) specific to pop-ups. It would be shame to let our long-history of non-standard pop-up blocking behavior stall/delay progress in the work to improve interop for the wide variety of features relying on simple "activation". If we can get all the other cases fully spec'd and on a path to full interop, that'll be a fantastic improvement (even if Chrome's pop-up blocking is still totally non-standard). Some of us are still hopeful that we can eventually achieve interop and full standardization around pop-ups, but concede that it shouldn't be the highest priority. Anne / Domenic, could you live with some pragmatic middle ground like this for now?

This seems a little disappointing to me. It greatly reduces the impact of user activation work, in my opinion, if we don't take the original and most important use case---pop-up blocking---into account. I'd be hesitant to invest many resources in fixing the spec or trying to get browsers on board if we're going to leave such a hole in our interop story. It also is worrying that any system we come up with for the other use cases is going to need to be abandoned or made more complicated if we eventually change course and attempt full interop, including pop-ups. In short, I think it'd be better for the web ecosystem if we don't end up with three concepts of user activation (pop-up user activation, user activation, and sticky user activation) but instead just two (user activation and sticky user activation). And I don't think routing through three concepts is a good way to get to two, at least in the standards/interop space.

I think we should not give up on full user activation interop. If there are indications that Mustaq's work won't be sufficient for Chrome's user experience needs regarding popups, we should reevaluate either that work or our requirements on popup blocking.

If, from an engineering level, you think encoding three concepts in Chrome is better in the short term, then maybe that's OK. Since interop here is bad anyway, the likelihood of us getting the web stuck in a three-concept state forever is low. I do think that if we go this way in Chrome, we should not spend effort in the standards space on user activation, as we'll be unable to show other browsers that we've produced a useful, two-concept, web-compatible model that can be uniformly implemented. We should instead wait until we can accomplish that goal, and then turn back to the problem of standardization.

---

To be clear, I *still* think it's fine to ship this particular intent as a short-term fix. I am just sad that this intent has spawned a larger discussion which has concluded that Mustaq's work should no longer aim for universal applicability.

[Charles Harrison]

Brief update:

We've been running a permanent 50/50 of this experiment on Canary / Dev channels in M64. So far, none of our metrics tracking metrics popup UI changes are showing anything statistically significant, though the metrics can be quite noisy. There also hasn't been any developer feedback, though it is only canary/dev.

I don't have a strong opinion on the spec side, though as someone who has some familiarity with abusive sites I favor an approach which has the concept of consumption for all things activation related (even if it ends up being an optional part). Popups may be the pertinent example for Chrome right now, but many new features/interventions are hooking into activation and consumption is a powerful tool to prevent their abuse.

[Rick Byers]

As long as Mustaq and Domenic feel this isn't a big step backward for the long term plan I think we should just ship it and leave the larger "rationalize and standardize gesture behavior" problem as separate.  I wouldn't want to delay each tweak to improving UGI behavior too much based in the uncertainty here.  

Of course I also don't want to keep adding hacks and complexity that will make rationalization harder.  I don't think this is such a case though, right?

Charlie, you feel you're ready to ship and so are looking for LGTMs, right?

[Charles Harrison]

Yes, looking for LGTMs, or requests for more data. The safest bet is to extend the experiment to Beta / Stable to get more data but I'm not sure that's the best option for predictability. No matter what happens we'll have a killswitch in case we hit unforeseen problems.

[Rick Byers]

Mustaq/Domenic, do you think this is OK to go ahead without significantly complicating your long term plans?

If so you can count an LGTM1 from me (on vacation now so won't be checking email until Jan 8!).

[Mustaq Ahmed]

I expect some complication for our long term User Activation v2 plan but it shouldn't be a major one.  So fixing Chrome w/o standardizing the behavior sounds good to me.  Moreover, I agree with Domenic that it's unlikely for the web (which is already in a terrible state for user activation interop) to converge to our "three-concept" behavior.

[Domenic Denicola]

I’m happy to defer to Mustaq here. If he believes we’re on the right track long-term, then we should be :)

 

To be clear, my concern wasn’t about shipping this particular change, but about the attitude expressed that it’d be a “fantastic” end-result to end up with something almost-but-not-quite interoperable. (Namely, Chrome three-concept, then trying to push a two-concept version into the spec and other browsers.) I think my concerns have been heard, so I’m good to go.

 

From: Mustaq Ahmed [mailto:mus...@google.com]
Sent: Thursday, December 14, 2017 12:04
To: Domenic Denicola <d...@domenic.me>; Charles Harrison <cshar...@chromium.org>
Cc: Rick Byers <rby...@chromium.org>; Anne van Kesteren <ann...@annevk.nl>; Philip Jägenstedt <foo...@google.com>; Jochen Eisinger <joc...@chromium.org>; Ojan Vafai <oj...@chromium.org>; Chris Harrelson <chri...@chromium.org>; Domenic Denicola <dom...@chromium.org>; Eric Lawrence <elaw...@google.com>; blink-dev <blin...@chromium.org>; Mounir Lamouri <mlam...@google.com>
Subject: Re: [blink-dev] Re: Intent to Implement and Ship: Initiating main frame navigations consumes a user gesture

 

I expect some complication for our long term User Activation v2 plan but it shouldn't be a major one.  So fixing Chrome w/o standardizing the behavior sounds good to me.  Moreover, I agree with Domenic that it's unlikely for the web (which is already in a terrible state for user activation interop) to converge to our "three-concept" behavior.

[Chris Harrelson]

LGTM2 to proceed then. As discussed off-thread, let's also produce more public documentation of how behavior related to this intent works, to help developers cope with the current situation.

--

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/DM5PR05MB28928D2F01EC095522C50D0BDF0A0%40DM5PR05MB2892.namprd05.prod.outlook.com.

[Yoav Weiss]

Just to clarify, this intent and the 50/50 experiment is still for variant [1] that was described above, right?

If so, LGTM3

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/DM5PR05MB28928D2F01EC095522C50D0BDF0A0%40DM5PR05MB2892.namprd05.prod.outlook.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/CAOMQ%2Bw9-bJKBFd9hgzu3V4KpuG8Gn_6-5ExOG9MRgq9pSnuHdg%40mail.gmail.com.

[Charles Harrison]

Hey Yoav,

Yeah the variant [1] is the one I landed under a 50/50 canary/dev experiment.

I'll update this thread with some documentation about user gesture consumption when I can.

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/DM5PR05MB28928D2F01EC095522C50D0BDF0A0%40DM5PR05MB2892.namprd05.prod.outlook.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.

[Charles Harrison]

Here's a short explainer I wrote about user activation consumption. It contains a few examples of navigation cases:

https://docs.google.com/document/d/1mohg6bRELWpW95NPq4V7IDJjjpWwMPWC6JNU-DAPYGg/edit?usp=sharing