Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

User activation API #4009

Closed
wants to merge 1 commit into from
Closed

User activation API #4009

wants to merge 1 commit into from

Conversation

dtapuska
Copy link
Contributor

@dtapuska dtapuska commented Sep 6, 2018

This pull request builds on other pull requests. Specifically:
#3800
#3851

Please ignore the first two commits since they are reflective of the other pull requests.


💥 Error: Wattsi server error 💥

PR Preview failed to build. (Last tried on Jan 15, 2021, 7:58 AM UTC).

More

PR Preview relies on a number of web services to run. There seems to be an issue with the following one:

🚨 Wattsi Server - Wattsi Server is the web service used to build the WHATWG HTML spec.

🔗 Related URL

Command failed: /home/noderunner/wattsi/bin/wattsi /tmp/upload_f4019edeaf4803185b60a27060bae86d (sha not provided) wc3hssvfxkg default /tmp/upload_17c16a3cd38181289b0b9d045612cecc

If you don't have enough information above to solve the error by yourself (or to understand to which web service the error is related to, if any), please file an issue.

@dtapuska
Copy link
Contributor Author

dtapuska commented Sep 6, 2018

Cross referencing TAG request w3ctag/design-reviews#300

@dtapuska
Copy link
Contributor Author

@cdumez @smaug---- @travisleithead

Are other vendors interested in this design for exposing UserActivation information?

@sideshowbarker sideshowbarker added normative change addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest impacts documentation Used by documentation communities, such as MDN, to track changes that impact documentation labels Sep 11, 2018
source Outdated
user is currently interacting with <var>W</var> or its subframes. The flag is set every time
<var>W</var> is <span data-x="activates-a-window">activated</span>, and is reset either
<ul>
<li>after an expiry time defined by the browser, or</li>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering whether it will be possible for the transient activation flag to change its value during scrip execution, so that if (event.userActivation.isActive) { console.log(event.userActivation.isActive) } is guaranteed to log true? It could be a rare and hard-to-reproduce race condition if this is not guaranteed. On the other hand, guaranteeing it would mean that busy-waiting could allow the action to be delayed beyond the expiry time, and that's not a good incentive at all.

This depends on how this step is implemented, and the most straightforward implementation would probably involve an internal equivalent of setTimeout that can't run in the middle of a script. @dtapuska, do you think anything should be said here, either for implementers to uphold the guarantee, or that the guarantee doesn't exist?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The event user actviation API is a snapshot.

For navigator.userActivation it is a live object and it is possible. With a timeout API there will always be a race.

Another alternate is that you expose the timestamp of the last transient user activation. But the problem with that is you don't know what timeout the user agent uses.

@dtapuska
Copy link
Contributor Author

@cdumez @smaug---- @travisleithead

I tried to solicit opinions a month ago have you been able to look at this proposal?

@mustaqahmed
Copy link
Contributor

The navigator interface proposed here came up last month during our TPAC session on User Activation v2. There was consensus that this interface would be useful for testing UAv2: we want to be able to write web-platform-tests for user activation core without relying on other high-level APIs (that are gated by user activation), otherwise the tests would be affected by cross-browser differences in those high-level APIs.

There was also a brief discussion about using this interface to conditionally show a button "click here to ..." if transient activation expired because, say, the user spent too long in a file upload dialog.

@annevk @smaug---- @whsieh: please review this PR for the JS exposed state we need for UAv2 testing.

Copy link
Member

@annevk annevk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall this seems reasonable, but there are quite a few details that need tighter language. We also need a lot of test coverage to address all the various postMessage() APIs (might also require changes to service workers).

source Outdated
data-x="dom-MessageEvent-userActivation">userActivation</code> attribute will be snapshot objects,
that is a snapshot of the source's state.</p>

<pre><code class="idl" data-x="">[Exposed=(Window,Worker,AudioWorklet)]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does an AudioWorklet need this? Other worklets don't?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This matches what MessageEvent is defined in. Is MessageEvent wrong?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No that's correct, but does it make sense to message user activation to an audio worklet? Does it mean anything?

source Outdated Show resolved Hide resolved
source Outdated
@@ -73409,6 +73409,74 @@ END:VCARD</pre>
</ul>


<h4>The <code>UserActivation</code> interface</h4>

<p>The <span>user activation state</span> is provided via the <code>UserActivation</code>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the reason to not make this a mixin of sorts?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really follow which object we are talking about here. The partial interface on the Navigator?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, as it's also needed on the event, but I think it's probably for the best this way. We should put this directly on Navigator though.

Also, can you pass user activation into a worker, should this be exposed on WorkerNavigator?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Re a state in WorkerNavigator: I think a such state would be unnecessary:

  • A worker cannot have a UI surface where user can interact with it directly, right? So it cannot ever have its own user activation.

  • The idea of passing user activation state from the main thread to a worker (so that the worker can now open popups etc) is very thorny. We took back a past proposal for state delegation between iframes because we heard strong (and logical) pushback from security and privacy perspectives. And a worker is way more hidden/obscure to an end-user than an iframe!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it then not make more sense to only have it on WindowPostMessageOptions? Presumably passing it to a background tab is also not ideal?

source Outdated
<div w-nodev>

<p>The <dfn><code data-x="dom-UserActivation-hasBeenActive">hasBeenActive</code></dfn> attribute
must return the state of the <span>sticky activation flag</span>. If the object is live it must
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please get the flag from an object of sorts.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't follow this comment. The UserActivation object could be a snapshot in time or a live variation. I guess that can be kind of odd.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I meant that it's unclear where "sticky activation flag" comes from.

source Outdated
<var>messageClone</var>, the <code data-x="dom-MessageEvent-ports">ports</code> attribute
initialized to <var>newPorts</var>, and the <code
data-x="dom-MessageEvent-userActivation">userActivation</code> attribute initialized to
<var>userActivationSnapshot</var>.</p></li>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aren't you accessing an object created in potentially a different process here? I don't think that works.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How do we define this object as it serializes?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I understand the question. Could you elaborate?

Describe the interface and augment PostMessage options to contain the
required fields.

Fixes whatwg#4008
@mustaqahmed
Copy link
Contributor

I forked off only the navigator part of this PR into #8254

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
addition/proposal New features or enhancements impacts documentation Used by documentation communities, such as MDN, to track changes that impact documentation needs implementer interest Moving the issue forward requires implementers to express interest normative change
Development

Successfully merging this pull request may close these issues.

None yet

5 participants