[Webkit-unassigned] [Bug 225559] Implement standards-compliant user gesture tracking

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed May 12 05:19:28 PDT 2021


https://bugs.webkit.org/show_bug.cgi?id=225559

--- Comment #4 from Ashley Gullen <ashley at scirra.com> ---
> As we mentioned in https://bugs.webkit.org/show_bug.cgi?id=222262, the correct way to use async clipboard API is to initiate the write immediately where each item will be written via promise.

Oh, I didn't know that. I guess it doesn't work for writeText() though, so you need to go through the write() API for that. Part of my point is these rules are complicated and I don't believe Safari documents them all in any one place, so it's hard to figure out combinations of what works and what doesn't work.

Another case I can illustrate is: suppose we want to do a bit of async work and then open a popup window. Safari blocks the popup, but Chrome allows it.

> I'm a bit confused here. OffscreenCanvas isn't supported in Safari. Are you talking about the hypothetical future in which Safari supports OffscreenCanvas?

Yes - it looks like OffscreenCanvas is nearly ready to ship in Safari, but we will not be able to use it on account of user gesture restrictions in Safari.

In Chrome, we have an architecture where we run our entire game engine in a Web Worker, rendering with OffscreenCanvas. This is good for performance isolation as it moves the entire performance overhead of our engine off the main thread. Input events are forwarded to the worker via postMessage(). However workers do not have access to APIs like requestFullscreen(). So if we need a DOM API, we postMessage() back to the DOM with an instruction to make the corresponding call. This works in Chrome, but in Safari this does not propagate the user gesture so blocks the call.

To illustrate this all more clearly I made a quick demo: https://downloads.scirra.com/labs/safariusergesture/index.html

'Open popup after 500ms timer' shows that opening a popup in a setTimeout() callback is allowed, up to a limit. It looks like Safari uses a limit of 1 second in other places, so I guess this applies to setTimeout() too.

'Open popup after async blob read' shows that if you await a FileReader operation for so much as a fraction of a second, Safari loses the user gesture and blocks the subsequent popup - even though it would have been allowed for up to 1 second with setTimeout(). This serves only to impede legitimate use cases.

'Open popup after postMessage roundtrip to worker' demonstrates the architecture we would use with OffscreenCanvas. Again a postMessage() roundtrip loses the user gesture, even though it completes well within 1 second.

All three cases work in Chrome, but only the first works in Safari.

I think the main question is: if user gestures are allowed for up to 1 second anyway, why make it API-specific? It just restricts legitimate use cases, and does not offer any privacy/security benefit as abusive content can still do what it wants within a 1 second window via setTimeout(). Chrome's user gesture model also uses a short timeout, but it doesn't limit the APIs used. So it seems this is just a web compatibility win with no downside.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210512/7f6df399/attachment.htm>


More information about the webkit-unassigned mailing list