New permission definitions are wrong.

[jan-ivar]

Sorry for not becoming aware of this sooner, but it's deeply concerning to me that we seem to recently have tied ourselves to the definitions in the document describing the web-facing Permissions API, which seems primarily to be about how web pages can view the state of persistent permissions ('prompt'/'granted'/'denied').

That whole spec is built on that triumvirate of states, making it inherently suited for requesting the state of persistent permissions only. They're necessarily persistent, because permission absent context needs to persist for some length of time, as it's not tied to anything else, like a successfully requested object.

This seems like an impedance mismatch for our needs. Our spec needs definitions for request for access, which we should be careful not to confuse with request for (persistent) permission. This is perhaps most obvious with the state 'prompt', which means the user gets a prompt when they later request access.

Clearly request for access must be separate from request for permission or there's a circular definition, yet their request for permission algorithm just returns the aforementioned triumvirate (I pick apart that algorithm in w3c/permissions#85 (comment)).

[alvestrand]

I believe you are mistaken in your reading.

A request for access (as detailed in https://w3c.github.io/mediacapture-main/getusermedia.html#methods-5) may cause a permission to be stored - or it may not. That's an implementation and UI issue.

The special condition "we already have the device open" is covered in step 3 and the first line of step 7.

I agree that "request access" is a better name than "request permission" for the action that is performed at step 7, because it's less likely to be confused with "create a permission and store it".

[jan-ivar]

@alvestrand, isn't _request a permission_ an algorithm for elevating (persistent) permissions, that resolves with either 'prompt', 'granted' or 'denied'?

Our getUserMedia algorithm seems to mistake this algorithm for a yes/no access request algorithm with only two possible outcomes: 'granted' or 'denied'. Square peg, round hole.

How should getUserMedia treat a 'prompt' result? 'prompt' after all, refers to what users will get when they later request access. In other words, this can't be the request access algorithm, or it's recursive.

Separately, the language about "live" tracks implying 'granted' is busted. A) that's not how Firefox ever worked (you get a prompt regardless), and B) the language implies site B gets access if site A has a live stream, which I don't think anyone wants.

[alvestrand]

@jan-ivar a yes/no outcome was what I wanted when I wrote that text. The term "request permission" was coined by me while writing it, so I'm pretty certain what was intended. As agreed above, I agree that "request access" is a better name for it.

Re "live" tracks: If Firefox does not grant automatic permission to reopening the same device to a new track, then Firefox has a bug, because that's what the spec's said one should do, and did so before my rewrite. Chrome has lots of bugs compared to the spec, so Firefox is not alone; one can't use the implementations to figure out what the spec says. (One can use it for arguing what the spec SHOULD say, but that's a different argument).

The language was intended to talk about live tracks in the same context. If this isn't clear, please open a separate bug for that.

[jan-ivar]

Re "live" tracks: If Firefox does not grant automatic permission to reopening the same device to a new track, then Firefox has a bug, because that's what the spec's said one should do, and did so before my rewrite.

@alvestrand here's the spec from February. Please find me where it says that.

I see no such language before your edit 29 days ago.

[stefhak]

@jan-ivar don't you agree to that if one track is using a camera, another track (on same origin) should be able to? This would happen if you clone a track as an example.

[jan-ivar]

@stefhak Thanks for asking. Yes, I think there are good reasons for considering such a change, including the one you mention.

Maybe if editors didn't bury unilateral changes so well, we could react faster and fix our stuff to comply.

[fluffy]

I just want to make sure I understand intent here. If I have two camera A and B, and the user grants permission for a given origin to use camera A, that does not mean that the origin can use camera B. Is that correct?

[alvestrand]

That has definitely been the intent.
The platform is free to give the user the option to grant access to all cameras (and even to only present this option to the user, as Chrome does by default), but the spec can't depend on that.

[alvestrand]

Note: w3c/permissions#120 made some permissions spec updates that are relevant.

[alvestrand]

Solved by #421