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

Promises should propagate UserGestureIndicator

Project Member Reported by, Aug 15 2014

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.
Labels: -Cr-Blink Cr-Blink-DOM
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.

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

Naively, I'd say we should find a way to propagate the user gesture for a second across several promises.
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 :(
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?
+japhet@ who has been doing some overhaul of our UserGestureIndicator code lately
Project Member

Comment 13 by, Oct 17 2016

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}


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.
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.
Blocking: 696617
 Issue 697832  has been merged into this issue.
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?
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.
Blocking: -696617
Blockedon: 696617
Labels: Hotlist-Input-Dev
Status: Assigned (was: Available)
mustaq@ will be looking into some of this next quarter.
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.
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?
Components: -Blink>DOM
Blocking: 760848
Labels: UserActivation
Any chance we can prioritize this issue?
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.
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:
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?
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.
Just confirmed that with chrome://flags/#user-activation-v2 enabled, the issue seems fixed, yayy!  I used the repro in #c31.
Blocking: -760848
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!!
Great news! Mustaq, when are you planning to launch the project?
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.
Blocking: 807738

Sign in to add a comment