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: jan-ivar via GitHub <sysbot+gh@w3.org>
Date: Thu, 08 Sep 2016 01:20:31 +0000
To: public-media-capture-logs@w3.org
Message-ID: <issue_comment.created-245467647-1473297629-sysbot+gh@w3.org>
> 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.

@stefhak I think you're parsing it incorrectly. [permission 
state](https://w3c.github.io/permissions/#permission-state) says:

*"2. If there was a previous invocation of this algorithm with the 
same descriptor and current settings object, returning previousResult,
 and the UA has not received [new information about the user’s 
 since that invocation, return previousResult. "*

In other words, the definition we're now leaning on is a permission 
state that inherently lingers within the current realm, making any 
"stored" distinction meaningless. While the definition of "user's 
intent" is quite broad, it's hard to see how it would cover a script 
deciding to stop all its tracks.

That this is unintentional seems clear, as much of the language in 
mediacapture, such as the tracking of whether devices are open, 
becomes largely redundant in this new model, as it now serves only to 
override "user intent" (because the only time it'd have an effect 
would be to counter a user's intent to actively change "granted" back 
to "prompt").

This is a clash of models, and preserving intent through a transition 
of models is tricky, especially when the meaning of language shifts.

To do so, we need to take a snapshot of behaviors "before" (February),
 and "after", and compare. Do we agree that in February, Edge's 
`https` behavior was non-compliant, whereas today it's the norm? 
That's a bug, or a change in outcome I think warrants new WG 

GitHub Notification of comment by jan-ivar
Please view or discuss this issue at 
 using your GitHub account
Received on Thursday, 8 September 2016 01:20:40 UTC

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