User Activation v2 feature detection |
||
Issue descriptionWe need a way to feature detect UAv2. I think any functional detection (e.g. clicking in a parent frame doesn't make user activation available in a subframe) would have to wait for a real (trusted) user interaction, and the waiting looks like an unacceptable constraint for cases where the feature detection is needed on loading. We can possibly use the JS API ( Issue 846858 ) as a proxy. We need to explore other possibilities. Any suggestions? --- The feature detection question came up in a private thread re avoiding repeated setTimeouts to make XHR work today. This workaround (which is suggested in Issue 760848#c7) won't be needed once UAv2 ships but only as a fallback solution for non-UAv2 browsers.
,
Jul 16
I wouldn't like to bake into the Web platform a feature detection for this, given that UAv2 isn't really a web-facing feature, it's a fix to a Chrome-specific bug. Developers have been working around the Chrome-specific bugs regarding user activation, and they'd like to detect when they can stop working around these bugs. But I think exposing a way to know whether the bugs are fixed will cause long-term pain as we'll have to support that feature detection forever. Better to just tell developers to user-agent-detect the Chrome version where these bugs were fixed, and disable the work-arounds, then remove them after a few months.
,
Jul 16
Suggesting to utilize UA-detection makes sense in the short term, so dropping the priority. Note however that we plan to fix the web through this feature, hence plan to propose a rewrite of most of the spec. If all goes as planned, it's better to have a feature detection, right?
,
Jul 18
> Note however that we plan to fix the web through this feature, hence plan to propose a rewrite of most of the spec. Sorry, do you mean to change the way user activation token works in the HTML spec? In what way? Do you have a GitHub issue open on the spec for this? I'm not sure what would be needed in the spec. For example, Issue 760848 is just a Chrome bug; there's nothing needed to add to the spec for this, just Chrome is not implementing the spec correctly by dropping the user activation token when queued by XHR. > If all goes as planned, it's better to have a feature detection, right? If it's a change to the web platform, then having a way to feature-detect the new capabilities in the HTML spec makes sense. If it's just a fix to Chrome then I don't think we want to provide feature detection for that fix.
,
Jul 18
With User Activation v2, we are getting rid of all stack-scoped tokens (and per-API token passing/storing etc), which fixes the prominent issues with Promise, XHR, setTimeout call depth etc (see the blocker bugs for Issue 696617). As expected, UAv2 calls for a big change in the current spec which should be okay since the spec doesn't sufficiently reflect the real implementations anyways. Here is the spec issue: https://github.com/whatwg/html/issues/1903
,
Nov 6
As mentioned in the original post, the feature detection for Issue 846858 (which is shipping in M72 too) could be used as a proxy for detecting UAv2 in Chrome. So "WontFix" for now, we can always reopen if the situation changes. |
||
►
Sign in to add a comment |
||
Comment 1 by mustaq@chromium.org
, Jul 13