W3C home > Mailing lists > Public > public-media-capture-logs@w3.org > September 2016

Re: [mediacapture-main] Reinstate strong language on permission ending when tracks stop, lost by editorial mistake

From: stefan hakansson via GitHub <sysbot+gh@w3.org>
Date: Wed, 07 Sep 2016 12:05:17 +0000
To: public-media-capture-logs@w3.org
Message-ID: <issue_comment.created-245259630-1473249915-sysbot+gh@w3.org>
Reading the Editor's draft I find the following blocks relevant:

In the sections about MediaStreamTrack:
```A script can indicate that a MediaStreamTrack object no longer 
needs its source with the stop() method. When all tracks using a 
source have been stopped or ended by some other means, the source is 
stopped. If there is no stored permission for the source, the User 
Agent SHOULD also remove the "permission granted" indicator for the 
source. If the data is being generated from a live source (e.g., a 
microphone or camera), then the User Agent SHOULD remove any active 
"on-air" indicator for that source. An implementation may use a 
per-source reference count to keep track of source usage, but the 
specifics are out of scope for this specification.```


A muted or disabled MediaStreamTrack renders either silence (audio), 
black frames (video), or a zero-information-content equivalent. For 
example, a video element sourced by a muted or disabled 
MediaStreamTrack (contained within a MediaStream ), is playing but the
 rendered content is the muted output. When all tracks connected to a 
source are muted or disabled, the "on-air" or "recording" indicator 
for that source can be turned off; when the track is no longer muted 
or disabled, it MUST be turned back on.```

In the section about gUM:
```Retrieve the permission state for all candidate devices in 
candidateSet that are not attached to a live MediaStreamTrack in the 
current browsing context. Remove from candidateSet any device for 
which the permission state is "denied".```


```For the origin identified by originIdentifier, request permission 
for use of the devices, while considering all devices attached to a 
live MediaStreamTrack in the current browsing context to have 
permission status "granted", resulting in a set of provided media.```


```If the result of the request is "granted", User Agents are 
encouraged to include a prominent indicator that the devices are "hot"
 (i.e. an "on-air" or "recording" indicator), as well as a "device 
accessible" indicator indicating that the page has been granted access
 to the source.```

To me it seems pretty clear. "request permission" links to the 
permission spec, which (if I parse it correctly) makes the UA deny, 
prompt the user or grant the request depending on the situation 
regarding for example stored permissions.

If all tracks are stopped followed by a gUM call, there would be a 
prompt if there was no stored permission.

That said, perhaps there would be a gain in modernizing the language 
as @jyasskin proposes (at the very least we should decide if we say 
'"device accessible" indicator' or '"permission granted" indicator').

GitHub Notification of comment by stefhak
Please view or discuss this issue at 
 using your GitHub account
Received on Wednesday, 7 September 2016 12:05:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:27:30 UTC