Re: [mediacapture-main] What happens when a machine suspends? (#668)

> Sorry that was confusing. What I meant to say was I opened #670 to make `mute` and `unmute` on _camera_ and _microphone_ tracks work consistently in all browsers, not to make them consistent with other specs (other specs are on their own).

They all link back here. This specification is primary source for `MediaStream` and `MediaStreamTrack`. It is not possible to avoid addressing the wild inconsistency between Chromium and Firefox as to `mute`, `unmute`, and `ended` of `MediaStreamTrack` when actually testing the implementation of this specification at modern browsers. Yet, for an unclear reason the momentum is to add more load to `mute`, `unmute` and `ended`, which by result of the reference back to this specification for the extensions will further make the `MediaStream` and `MediaStreamTrack` implementation with a core document where their own is really not their own, their own is using the "branded" `MediaStream` and `MediaStreamTrack`. 

Why is "What happens when a machine suspends?" a compelling concern?  

Do the specification authors intended to actually perform field research, or only speculate from the top-down as to what should occur when "a machine suspends"? 

Is this a directive from you parent corporation or other subsidiary working group to address that issue?

What happens when a user does not want browser source code to be constantly checking some vague notion of what "when a machine suspends" is supposed to mean and wants to opt-out of the concept of `getUserMedia()` is spying on when the laptop lid is closed, or some other arbitrary and intrusive browser code?

GitHub Notification of comment by guest271314
Please view or discuss this issue at using your GitHub account

Received on Friday, 27 March 2020 01:28:22 UTC