Expose the timestamp associated with a user gesture, and make it possible to recreate a new user ge…

Expose the timestamp associated with a user gesture, and make it possible to recreate a new user gesture token with that timestamp.

BUG=354217

[Marijn Kruisselbrink, 2014-04-16 21:43:40]

In the extension system when one extension sends a message to another one (or to
itself) we pass along if a user gesture is currently being processed. The idea
here was that this would allow an app or extension to do things that require a
user gesture in response to a message it received, as long as the message was
send in the context of a user gesture.
Now since we're essentially creating a new user gesture in the receiving
renderer process this opens up a way to bounce around a user gesture
indefinitely, bypassing the timeout a user gesture normally comes with. This CL
is an attempt to solve that (the chrome-side of this change is
https://codereview.chromium.org/240223004/).

I'm not entirely convinced this is the right solution though. Exposing the
timestamp like this feels a bit hacky (also it relies on WTF::currentTime to be
the same in all renderer processes, which I'm not sure is a valid assumption;
maybe passing elapsed time instead of absolute timestamps would be better).
Another solution that seems less hacky, but more complicated, would be to give
(Web)UserGestureToken some way to serialize itself, and then add a way to
recreate a (Web)UserGestureToken from that serialized format. This is (among
other things) complicated by the fact that currently creating a
WebScopedUserGesture with an existing token will reset the timestamp of the
token, so that would need changing too.

So does this seem at all like a reasonable approach? (if so, I know I still need
to add unit tests etc)

[jochen (gone - plz use gerrit), 2014-04-17 08:11:02]

The user gesture indicator stuff is not meant to be cross-process.

If the extension is supposed to do something user gesture gated in the same
process the user gesture happened, then you should keep the user gesture token
in that process and just wait for the IPC to come back. We do this e.g. for
PPAPI stuff: the renderer side ppapi proxy keeps the token, sends an IPC to the
plugin, waits for the response, and if the token is still valid by that time
(for cross process, the timeout is 10s btw), it can do something user gesture
gated.

If you want to pass around the user gesture, I don't think the timeout based
approach makes sense. We have a similar situation with setTimeout(): a
setTimeout() created within the scope of a user gesture carries the user gesture
with it, however, if you create yet another setTimeout from within the timeout
handler, we don't pass the gesture token, even if it's still valid.

For extensions this would mean that you'd pass the user gesture (as a bool) once
and create a WebScopedUserGesture on the other side. But the other side is not
able to pass it along anywhere else

wdyt?

[Marijn Kruisselbrink, 2014-04-17 17:47:26]

On 2014/04/17 08:11:02, jochen (OOO until Apr 22) wrote:
> The user gesture indicator stuff is not meant to be cross-process.
> 
> If the extension is supposed to do something user gesture gated in the same
> process the user gesture happened, then you should keep the user gesture token
> in that process and just wait for the IPC to come back. We do this e.g. for
> PPAPI stuff: the renderer side ppapi proxy keeps the token, sends an IPC to
the
> plugin, waits for the response, and if the token is still valid by that time
> (for cross process, the timeout is 10s btw), it can do something user gesture
> gated.
Unfortunately in this case generally this goes from one renderer process to a
different renderer, otherwise that would definitely have been the way to go.

> If you want to pass around the user gesture, I don't think the timeout based
> approach makes sense. We have a similar situation with setTimeout(): a
> setTimeout() created within the scope of a user gesture carries the user
gesture
> with it, however, if you create yet another setTimeout from within the timeout
> handler, we don't pass the gesture token, even if it's still valid.
Actually, setTimeout does both, it only seems to carry the user gesture when the
timeout is less than one second?

> For extensions this would mean that you'd pass the user gesture (as a bool)
once
> and create a WebScopedUserGesture on the other side. But the other side is not
> able to pass it along anywhere else
Hmm, yeah, something like that might have been a good idea... Unfortunately the
original user gesture passing with extension messages got rushed out a bit too
quickly, and limiting it like this now would be backwards incompatible. I'm
pretty sure that at least one of the first-party apps that we implemented this
for in the first place actually relies on being able to forward the same user
gesture twice.

But okay, lets assume that it wouldn't break things too badly, implementing that
properly would still be rather non-trivial. Just adding another nesting level to
make sure I'm not passing on a user gesture that was originally passed on with a
message won't be enough. The nesting level setTimeout uses and the nesting level
I would use need to be the same for this to work (somehow storing the "this is a
forwarded token" state as part of the user gesture token might work, although
that would have issues too).

[jochen (gone - plz use gerrit), 2014-04-17 17:53:37]

Can you give a concrete example of an app that forwards a gesture twice?

[Marijn Kruisselbrink, 2014-04-17 18:18:13]

On 2014/04/17 17:53:37, jochen (OOO until Apr 22) wrote:
> Can you give a concrete example of an app that forwards a gesture twice?
The app I was thinking of was Google Play Music (which forwards user gestures
from the app to its accompanying web page and vice versa), where I think at
least at some point they did this in a two step way, first by posting a message
from the app window to the app background page, and then from there posting a
message from the background page to the play website. I'm not sure if they're
still doing this, and technically the communication between app window and
background page could be done directly without posting messages. So yeah, I'm
not sure if there are any usecases that could only be accomplished by forwarding
a user gesture twice.

[Marijn Kruisselbrink, 2014-04-25 21:41:00]

Okay, I think forwarding twice is indeed not particularly useful, so I went
ahead and implemented your idea in https://codereview.chromium.org/258783004/