-
Notifications
You must be signed in to change notification settings - Fork 61
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
Allow gUM prompt ahead of focus + deterministic "visible" enumeration wo/focus #912
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally LGTM.
getusermedia.html
Outdated
<p>If <var>proceed</var> is `false`, the [=User Agent=] | ||
MUST wait to proceed to the next step until a task queued | ||
to set <var>proceed</var> to the result of | ||
[=device enumeration can proceed=], sets | ||
<var>proceed</var> to `true`.</p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The prose here was difficult for me to process. How about simplifying it with something along the lines of "...queue a task to do X. Once the task resolves, proceed to the next steps."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm open to simpler ways to say it, but queued tasks don't "resolve" AFAIK. Also, waiting for the task alone is not enough, since that might proceed on false
. The intent here is to describe the same criteria as before without the cross-thread access.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've done a tweak with s/If/While/ combined with broken out algorithms that are hopefully easier on the eyes. PTAL.
getusermedia.html
Outdated
the [=relevant global object=]'s [=associated `Document`=] is | ||
[=Document/fully active=] and its [=Document/visibility state=] | ||
is `"visible"`.</p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As a follow up, I wonder if we could refine our concept of focus to accommodate the possibility that UA-level elements might override the app's focus even when visible, e.g. if the user is interacting with DevTools, the omnibar, bookmarks drop-down lists, or any future UA-level element of arbitrary complexity which could be prominently displayed and commanding the user's attention.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that's whatwg/html#6211, which is hopefully not a blocker for this PR which moves us a step closer.
@guidou is this deployable? |
I think this is an improvement over the focus requirement. In terms of deployability, we'll have to implement and evaluate it. The focus requirement introduced serious regressions for many of Chromium users and we had to roll it back. |
jump to the step labeled <em>Permission Failure</em> below.</p> | ||
</li> | ||
<li> | ||
<p>Let <var>hasSystemFocus</var> be `false`.</p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this mean we still need to have system focus?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In getUserMedia, yes. The focus requirement here is just moved down to allow prompting ahead of focus, like Safari does.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems to be a more deployable change than the change from present behavior that is currently in the spec, so it's an improvement. We'll see if it can deploy.
Remove focus from mute/unmute SHOULD prose to match #912 best practice.
Remove focus requirement on enumerateDevices, for real this time #912.
Fixes #752:
navigator.mediaDevices.enumerateDevices()
require thatDocument
must have active keyboard focus? #905 (comment) which prevented deterministic visibility-success checks:Preview | Diff