New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 18 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows , All
Pri: 3
Type: Feature

Blocked on:
issue 696617

Blocking:
issue 807738



Sign in to add a comment
link

Issue 404161: Promises should propagate UserGestureIndicator

Reported by mlamouri@chromium.org, Aug 15 2014 Project Member

Issue description

To some extent, we should be able to chain promises without loosing the user gesture bit.

For example, it would allow calling requestFullscreen() in a promise handler that was setup in a user gesture event handler (like a click). Or input.click() for an <input type='file'>.

I believe we do that kind of stuff for setTimeout() for a deepness of 1. Maybe we could increase the deepness but 1 would be a good start.
 

Comment 1 by cbiesin...@chromium.org, Nov 30 2015

Labels: -Cr-Blink Cr-Blink-DOM

Comment 2 by dominicc@chromium.org, Dec 1 2015

Labels: -Type-Bug -Pri-2 Type-Feature Pri-3
Status: Available
Sounds reasonable; is there a spec for this? What about the security-minded JavaScript author, is their API to slough off the UGI? I'm going to put this in the feature request bucket for now. It might be a useful first step to survey all of our delayed callback mechanisms, because we keep adding them (rAF, rIdleFrame, Promises) and see how they all handle UGI versus classic ones. Like postMessage, Promises can go cross-process through APIs like Service Worker. It's a complicated area!

Comment 3 by monte...@gmail.com, Mar 22 2016

I think I'm getting bit by this.

Pretty simple case: 

I'd like to use navigator.usb.getDevices() to check for previously authorized USB devices.  If none exist, then prompt the user for authorization.

Problem is that the getDevices() promise next ticks and loses gesture, so the navigator.usb.requestDevice() call will error.

Here's the code where it's happening: https://github.com/monteslu/webusb-serial/blob/master/index.js#L18-L24
This of course results in an "Must be handling a user gesture to show a permission request."  error.

-Luis

Comment 4 by fbeaufort@chromium.org, Aug 11 2016

Owner: jochen@chromium.org
jochen@ Could you have a look at this?

Comment 5 by jochen@chromium.org, Sep 22 2016

setTimeout doesn't propagate the user gesture for more than a second, nor can you chain setTimeouts.

If we just translate this to promises, we end up with a very odd API:

the first promise microtask would get the user gesture, but the second wouldn't? Or should we drop the user gesture after the first microtask checkpoint?

with setTimeout, you have some reasonable expectation to run before the second is over (assuming you specified a low enough timeout), but promises don't talk at all about when they run, so we might end up with pretty random / hard to debug behavior.

sooo.... spec first plz?

Comment 6 by jochen@chromium.org, Sep 22 2016

Cc: jochen@chromium.org
Owner: domenic@chromium.org

Comment 7 by fbeaufort@chromium.org, Sep 22 2016

Naively, I'd say we should find a way to propagate the user gesture for a second across several promises.

Comment 8 by jyasskin@chromium.org, Sep 22 2016

Jochen: https://html.spec.whatwg.org/multipage/interaction.html#triggered-by-user-activation says "The task in which the algorithm is running was queued by an algorithm that was triggered by user activation, and the chain of such algorithms started within a user-agent defined timeframe." https://html.spec.whatwg.org/multipage/webappapis.html#microtask says "a microtask is a task".

So this is already spec'ed to chain both setTimeouts and Promises, with a time limit.

Comment 9 by jochen@chromium.org, Sep 22 2016

yeah, but I'd argue that this is a poor UX, as it won't be able to chain promises in a meaningful way.

also, this spec is pretty far away from what is actually implemented :(

Comment 10 by domenic@chromium.org, Oct 3 2016

What is the actual action item for me here? It sounds like the spec already says enough to allow user gesture propagation. However, jochen@ is not a fan of the manner in which it does so? But I don't see any good way of doing so that would be good (i.e. avoid "random / hard to debug behavior"). jochen@, do you have any suggestions?

Comment 12 by rbyers@chromium.org, Oct 15 2016

Cc: japhet@chromium.org rbyers@chromium.org
+japhet@ who has been doing some overhaul of our UserGestureIndicator code lately

Comment 13 by bugdroid1@chromium.org, Oct 17 2016

Project Member
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/776722a66c9fcbc67da598656a167673d8790024

commit 776722a66c9fcbc67da598656a167673d8790024
Author: jyasskin <jyasskin@chromium.org>
Date: Mon Oct 17 23:14:54 2016

Count how many times user gesture tokens are merged.

In the "Blink.Gesture.Merged" histogram. This will help determine
if we can change the merging behavior when standardizing user
gestures.

BUG=404161

Review-Url: https://codereview.chromium.org/2417153003
Cr-Commit-Position: refs/heads/master@{#425807}

[modify] https://crrev.com/776722a66c9fcbc67da598656a167673d8790024/third_party/WebKit/Source/platform/UserGestureIndicator.cpp
[modify] https://crrev.com/776722a66c9fcbc67da598656a167673d8790024/third_party/WebKit/Source/platform/UserGestureIndicator.h
[modify] https://crrev.com/776722a66c9fcbc67da598656a167673d8790024/tools/metrics/histograms/histograms.xml

Comment 14 by bmcquade@chromium.org, Nov 17 2016

I encountered a related issue in  bug 666300 , where a page was listening for click events on <a> tags, then dispatching synthesized MouseEvents in the click event handler to drive the navigation.

Our current user gesture tracking doesn't consider this case to be initiated by user gesture, even though from a user standpoint it is indistinguishable from a normal link click.

I'm glad to see the proposal to improve gesture propagation, and I'm hopeful we can accomodate the case I encountered as well as part of fixing this issue.

Comment 15 by domenic@chromium.org, Feb 13 2017

Owner: ----
I'm going to unassign this to me as I maintain that the spec as-written allows what we want to do here. There is an interesting action item around aligning the spec with browsers better, which is tracked in https://github.com/whatwg/html/issues/1903, but it does not block the work here in implementing the plan mentioned in comment #11, and will likely involve a lot of tricky compat work. In contrast, the issue at hand here that is causing developer pain is a lot simpler to solve.

Comment 16 by jyasskin@chromium.org, Feb 14 2017

Cc: jyasskin@chromium.org

Comment 17 by rbyers@chromium.org, Feb 27 2017

Blocking: 696617

Comment 18 by rbyers@chromium.org, Mar 3 2017

 Issue 697832  has been merged into this issue.

Comment 19 by rbyers@chromium.org, Mar 3 2017

Cc: dominicc@chromium.org dtapu...@chromium.org mustaq@chromium.org
Components: Blink>Input
I agree this seems important (eg. see  issue 697832 ).  It's not clear to me whether DOM or Input teams should own this.  dtapuska / dominicc WDYT?

Comment 20 by mlamouri@chromium.org, Mar 5 2017

FWIW, it's also in my team's backlog. It's not directly related to what we are doing but it makes the experience slightly annoying because of playback requiring a user gesture.

Comment 21 by rbyers@chromium.org, Mar 20 2017

Blocking: -696617

Comment 22 by rbyers@chromium.org, Mar 20 2017

Blockedon: 696617

Comment 23 by dtapu...@chromium.org, Mar 23 2017

Labels: Hotlist-Input-Dev
Owner: mustaq@chromium.org
Status: Assigned (was: Available)
mustaq@ will be looking into some of this next quarter.

Comment 24 by agektmr@chromium.org, May 12 2017

Labels: OS-Windows
Any updates on this? Problems caused by this issue comes up quite often and resolving this will help many aspects of the ecosystem.

Comment 25 by mustaq@chromium.org, May 12 2017

We are looking into an alternate design, see the blocker bug.

I think we already propagate gesture through Promises, at least with call depth 1 for sure. The behavior is not consistent with Edge, FF & Safari though.

Repro: mustaqahmed.github.io/web/popup-with-user-activation.html
Browser comparison: https://docs.google.com/document/d/1hYRTEkfWDl-KO4Y6cG469FBC3nyBy9_SYItZ1EEsXUA/edit#heading=h.my25nmtd7w07

mlamouri@: As per my experiment, this bug is fixed (I suspect through the sticky Frame::has_received_user_gesture_ but not certain). Do you agree? Or did you mean to cover a broader scope?

Comment 26 by hayato@chromium.org, Jul 6 2017

Components: -Blink>DOM

Comment 27 by mustaq@chromium.org, Sep 6 2017

Blocking: 760848

Comment 28 by mustaq@chromium.org, Nov 1 2017

Labels: UserActivation

Comment 29 by agektmr@chromium.org, Nov 27 2017

Any chance we can prioritize this issue?

Comment 30 by agektmr@chromium.org, Nov 27 2017

Let me give you more context on this issue.

I'm working on authentication stuff. A user clicking on a button pops up a window and authenticates the user on a third party website. But an intermediary dialog injected by the Credential Management API which returns a promise terminates the gesture chain and it prevents popup window to be opened.

Comment 31 by agektmr@chromium.org, Nov 27 2017

To reproduce the issue:
1. go to https://credential-management-sample.appspot.com/
2. sign-in using a google account with google sign-in button
3. save the credential when a dialog appears
4. sign out from https://credential-management-sample.appspot.com/
5. also sign out from google account at google.com
6. come back to https://credential-management-sample.appspot.com/
7. click on "sign in" on top right
8. select stored google account

now your popup should be blocked.

I used Chrome Canary on Mac (Version 64.0.3275.0).
The source code of the website can be found here: https://github.com/GoogleChrome/credential-management-sample

Comment 32 by mustaq@chromium.org, Feb 5 2018

agektmr@: sorry for the delay, just got a chance to look into this now.

I was trying to check if the bug reproduces with our new model (i.e. chrome://flags/#user-activation-v2 enabled).  Want to clarify what you meant by "your popup should be blocked": did you mean the page should just sign in without any password prompt?  Or you meant only some popup window?

Comment 33 by vasi...@chromium.org, Feb 13 2018

He meant that the page tries to open a Google sign-in popup window after step 8 (because the user is signed out on Google). That popup is blocked however despite it's logically a follow up on "sign in" click at step 7.

Comment 34 by mustaq@chromium.org, Feb 27 2018

Just confirmed that with chrome://flags/#user-activation-v2 enabled, the issue seems fixed, yayy!  I used the repro in #c31.

Comment 35 by mustaq@chromium.org, Feb 27 2018

Blocking: -760848

Comment 36 by agektmr@chromium.org, Feb 28 2018

Sorry for lagged response. I didn't know that the flag needs to be enabled.
I just turned it on and tried the same procedure and proved that it works.
Thanks for solving the long standing issue!!

Comment 37 by vasi...@chromium.org, Feb 28 2018

Great news! Mustaq, when are you planning to launch the project?

Comment 38 by mustaq@chromium.org, Feb 28 2018

agektmr@: to clarify, the flag is not enabled by default, so most user won't see the fix until we launch the feature.

vasilii@: we are expecting to launch v2 in M67 or M68.

Comment 39 by vasi...@chromium.org, Mar 12 2018

Blocking: 807738

Comment 40 by gutemb...@outlook.com, Oct 31

I have the same issue in WebUSB requestDevice() call.

I can confirm that with chrome://flags/#user-activation-v2 enabled it works.

Its being a while since last update on this issue, so can we have an estimation on when it will be pushed to a chrome update?

I'm on Version 70.0.3538.77 (Official Build) (64-bit) and it still disabled by default.

We are blocked moving forward with WebUSB because of this :(

Comment 41 by mustaq@chromium.org, Oct 31

We are expecting to UAv2 ship in Chrome 72.  I will update the blocker bug.

Comment 42 by gutemb...@outlook.com, Oct 31

@mustaq 

Awesome news! However, I looked on https://www.chromium.org/developers/calendar and there is no 72 stable plans... 

Can you estimate when it will arrive on stable channel so regular users can have access to it?

Thanks!

Comment 44 by gutemb...@outlook.com, Nov 6

@mustaq

Ok cool. We tried to use the same features on Chrome for Windows, but it doesn't work regardless if I have the flag enabled or not.

The device.open() call return a "Access denied" error. It is important to notice that it only happens on Windows. On OSX it works just fine... 

Is it related? Can you shed a light?

Thanks!

Comment 45 by mustaq@chromium.org, Nov 6

UAv2 doesn't do anything OS-specific.  I suspect #c44 is a WebUSB implementation bug, could be related to Issue 637404#c3.

Comment 46 by agektmr@chromium.org, Jan 15

When do you enable this feature by default? What is a blocker?

Comment 47 by a...@scirra.com, Jan 15

Isn't this superseded by User Activation v2? It's shipping in M72.

Comment 48 by mustaq@chromium.org, Jan 15

Yes, UAv2 is shipping in M72 (already available in Beta).  We will close Issue 696617 and other related bugs (like this one) later to give it some time in the wild.

Comment 49 by agektmr@chromium.org, Jan 16

That is a great news. Thank you!

Comment 50 Deleted

Sign in to add a comment