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
EstimatedDays: ----
NextAction: ----
OS: Windows , All
Pri: 3
Type: Feature

Blocked on:
issue 696617

issue 807738

Sign in to add a comment

Issue 404161: Promises should propagate UserGestureIndicator

Reported by, 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 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, Nov 30 2015

Labels: -Cr-Blink Cr-Blink-DOM

Comment 2 by, 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, 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:
This of course results in an "Must be handling a user gesture to show a permission request."  error.


Comment 4 by, Aug 11 2016

jochen@ Could you have a look at this?

Comment 5 by, 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, Sep 22 2016


Comment 7 by, 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, Sep 22 2016

Jochen: 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." 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, 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, 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, Oct 15 2016

+japhet@ who has been doing some overhaul of our UserGestureIndicator code lately

Comment 13 by, Oct 17 2016

Project Member
The following revision refers to this bug:

commit 776722a66c9fcbc67da598656a167673d8790024
Author: jyasskin <>
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


Cr-Commit-Position: refs/heads/master@{#425807}


Comment 14 by, 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, 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, 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, Feb 14 2017


Comment 17 by, Feb 27 2017

Blocking: 696617

Comment 18 by, Mar 3 2017

 Issue 697832  has been merged into this issue.

Comment 19 by, Mar 3 2017

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, 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, Mar 20 2017

Blocking: -696617

Comment 22 by, Mar 20 2017

Blockedon: 696617

Comment 23 by, Mar 23 2017

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

Comment 24 by, 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, 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.

Browser comparison:

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, Jul 6 2017

Components: -Blink>DOM

Comment 27 by, Sep 6 2017

Blocking: 760848

Comment 28 by, Nov 1 2017

Labels: UserActivation

Comment 29 by, Nov 27 2017

Any chance we can prioritize this issue?

Comment 30 by, 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, Nov 27 2017

To reproduce the issue:
1. go to
2. sign-in using a google account with google sign-in button
3. save the credential when a dialog appears
4. sign out from
5. also sign out from google account at
6. come back to
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:

Comment 32 by, 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, 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, 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, Feb 27 2018

Blocking: -760848

Comment 36 by, 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, Feb 28 2018

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

Comment 38 by, 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, Mar 12 2018

Blocking: 807738

Comment 40 by, 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, Oct 31

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

Comment 42 by, Oct 31


Awesome news! However, I looked on 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?


Comment 44 by, Nov 6


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


Comment 45 by, 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, Jan 15

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

Comment 47 by, Jan 15

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

Comment 48 by, 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, Jan 16

That is a great news. Thank you!

Comment 50 Deleted

Sign in to add a comment