It is unclear which of PermissionStatus change event or MediaStreamTrack ended event should fire first in case Permission is revoked

[youennf]

The order of firing the events is unclear to me when reading the spec.
I have a slight preference for firing the PermissionStatus event first.

Also, https://w3c.github.io/permissions/#media-devices should ideally link to https://w3c.github.io/mediacapture-main/#ends-nostop in the section dealing with stopping MediaStreamTrack when permission is revoked.

[jan-ivar]

The order of firing the events is unclear to me when reading the spec.

The order of reacting-to-revocation and PermissionStatus-update seems unclear, so this might affect all permissions. @jyasskin may know the intent.

I have a slight preference for firing the PermissionStatus event first.

Me too, in a cause and effect kind of way.

Also, https://w3c.github.io/permissions/#media-devices should ideally link to https://w3c.github.io/mediacapture-main/#ends-nostop in the section dealing with stopping MediaStreamTrack when permission is revoked.

This I think we can model on how ambient-light-sensor does it, but adding a "generic capture device permission revocation algorithm" to mediacapture, and calling it. I can do a PR in #439.

[guest271314]

Note, when a MediaStream is captured at Nightly using getUserMedia() and streamed to Chromium using RTCPeerConnection when the permissions are revoked at Nightly (indicator window closes) the MediaStreamTrack at Chromium does not fire mute or ended event. The track only stops when the Nightly page is reloaded.

[marcoscaceres]

Moved this issue from Permissions to mediacapture-main... as we move the permissions setup to this spec, it should (in theory) be possible to now specify the above in mediacapture-main (if not, let me know and I can make some fixes over in Permissions).

[jan-ivar]

What the permissions spec says now is: "When the permission lifetime expires for an origin:

1. Set the permission back to its default permission state (e.g., by setting it back to "prompt").
2. For each browsing context associated with the origin (if any), queue a global task on the permissions task source ... to run the permission revocation algorithm." ... which in our case "is the result of calling the device permission revocation algorithm", which "For each track ..., [ends] the track.", which means "queue a task that ... fire an event named ended"

A simple interpretation of this numbering (1,2) might suggest that that was also the intended order of events. However, if we take the queued tasks into consideration, it gets more complicated.

Step 2 here queues a task A per global to queue a task B per track to fire ended, which in total takes 2+ tasks.

Step 1 appears to invoke: "Whenever the user agent is aware that the state of a PermissionStatus instance status has changed, it ... runs the PermissionStatus update steps: ... 4. Queue a task on the permissions task source to fire an event named change at status."

IOW, Step 1 here queues a task C per global to fire change.

So change happens before ended.