Do 'triggered by user activation' check earlier

[marcoscaceres]

For normative changes, the following tasks have been completed:

• Modified Web platform tests (link to pull request)

Implementation commitment:

• WebKit (https://bugs.webkit.org/show_bug.cgi?id=)
• Chromium (https://bugs.chromium.org/p/chromium/issues/detail?id=)
• Gecko (https://bugzilla.mozilla.org/show_bug.cgi?id=)

[marcoscaceres]

Would prefer to do this check earlier in Gecko if possible.

[marcoscaceres]

Safari does the check later, so Gecko will follow Chrome and Safari.

[mgiuca]

IIRC the reason why this check comes after all the TypeErrors is a little dubious but deliberate: it makes it possible to write automated error tests that check for TypeErrors in the WPT suite. All tests that expect us to go past the user activation check have to be manual tests, because they will all fail if automated.

If the user activation check is moved up ahead, all the automated tests will fail with NotAllowedError.

[marcoscaceres]

IIRC the reason why this check comes after all the TypeErrors is a little dubious but deliberate: it makes it possible to write automated error tests that check for TypeErrors in the WPT suite. All tests that expect us to go past the user activation check have to be manual tests, because they will all fail if automated.

This was solved on WTP via Web Driver and .bless() (or just using .click(), which fires trusted events when run under automation).

[marcoscaceres]

This came up again during review on the Gecko side... given that we can deal with this correctly on WTP, @mgiuca would you be willing to change the Blink implementation?

[ewilligers]

Are you also proposing that canShare (if merged) would also require user activation? If not, what is the benefit of moving the check up?

I don't mind changing the order in the Blink implementation if that is the consensus. Any feedback from Safari?

[marcoscaceres]

Are you also proposing that canShare (if merged) would also require user activation?

No. But in the related issue (I think #5), I discussed how to separate the concerns between sharing from canShare.

If not, what is the benefit of moving the check up?

It's just convention in Gecko code and other APIs to do the "triggered by user activation" checks first - before doing all the data checks. So the benefit would be consistency with other APIs (and less Gecko reviewers telling me "move this up" 😂).

[mgiuca]

It doesn't make sense for canShare to require user activation.

I think the reason Eric raises this is that canShare is currently defined in the L2 spec as:

canShare(data) MUST return true unless share(data) would reject with TypeError, in which case it MUST return false.

That definition wouldn't work if we moved the user activation check up. But I think Marcos also objected to that definition (somewhere else) and that we should define it properly by abstracting out the type checking. Which I can get behind.

That aside, it also seems logical to me that the method would do input validation (i.e., checks that are pure mathematical function of the input) before doing extrinsic checks that rely on the state-of-the-world (i.e., checks about user activation).

It's just convention in Gecko code and other APIs to do the "triggered by user activation" checks first - before doing all the data checks.

If that's the case, is it also a convention in other web APIs (specs)? Can you point to other web specs that do user activation testing before input validation? If so, I'd be happy to change it.

[marcoscaceres]

That definition wouldn't work if we moved the user activation check up. But I think Marcos also objected to that definition (somewhere else)

Indeed. I think it was #108.

and that we should define it properly by abstracting out the type checking. Which I can get behind.

That would be great. It means doing less gymnastics in our implementation.

That aside, it also seems logical to me that the method would do input validation (i.e., checks that are pure mathematical function of the input) before doing extrinsic checks that rely on the state-of-the-world (i.e., checks about user activation).

I don't disagree... we kinda do this already:

1. binding layer does type checks, which, if you squint just right, would be the "pure mathematical function of the input".

But then we diverge on:

1. Security/input checks, including triggered by user activation, possibly feature policy checks, etc..
2. Do actual data mutations (e.g., resolve URL).
3. IPC... and so on....

If that's the case, is it also a convention in other web APIs (specs)? Can you point to other web specs that do user activation testing before input validation? If so, I'd be happy to change it.

Some examples:

• (biased, I wrote it) https://www.w3.org/TR/payment-request/#show-method
• (biased, I wrote it) https://w3c.github.io/screen-orientation/#apply-an-orientation-lock
• https://html.spec.whatwg.org/#file-upload-state-(type=file)

Somewhat in the middle:

• ("allowed to request fullscreen", relies on "triggered by use activation") https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen

[mgiuca]

Discussed offline; we are OK to keep it for now (those examples aren't particularly strong since they don't go TypeErrors after the activation check).