- From: Elad Alon via GitHub <sysbot+gh@w3.org>
- Date: Tue, 08 Mar 2022 13:19:37 +0000
- To: public-webrtc-logs@w3.org
> ...that can't be solved by the capturer inspecting the situation in other ways... If the capturing frame is cross-origin from the frame hosting the crop-target, this inspection requires asynchronous messaging, and there's a cost associated. Applications that need to react[*] won't be able to do so in a timely fashion. (Also hard to handle robustly, e.g. when the user repeatedly scrolls the crop-target in and out of view.) [*] That said, the applications I currently have in mind, would probably not allow crop-targets to be scrolled away. I cannot presently think of a realistic use-case where an application would really need this signal. That's why I'm happy removing the discussion of muting from the spec, and continue this discussion as a lower-priority issue. > Mute has traditionally been "this track is not producing data, this was intentional, **and we're not telling you why**". Non-rhetorical questions: Is the "not telling you why" part important? Is it important to hide the fact the user pressed "mute" in the browser's UX? And if so, do we have enough possible causes in the mute bin that "user **probably** muted" could not be inferred? Was it a conscious decision to hide the cause, and if so, is it worth "relitigating" it? -- GitHub Notification of comment by eladalon1983 Please view or discuss this issue at https://github.com/w3c/mediacapture-region/issues/9#issuecomment-1061768547 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 8 March 2022 13:19:38 UTC