W3C home > Mailing lists > Public > public-webrtc@w3.org > April 2020

[mediacapture-main] Shouldn't fire (un)mute event on already (un)muted track (#676)

From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
Date: Fri, 03 Apr 2020 21:54:31 +0000
To: public-webrtc@w3.org
Message-ID: <issues.opened-593661175-1585950870-sysbot+gh@w3.org>
jan-ivar has just created a new issue for https://github.com/w3c/mediacapture-main:

== Shouldn't fire (un)mute event on already (un)muted track ==
We shouldn't fire the [mute](https://w3c.github.io/mediacapture-main/getusermedia.html#event-mediastreamtrack-mute) event on an already muted track (`track.muted == true`).
We shouldn't fire the [unmute](https://w3c.github.io/mediacapture-main/getusermedia.html#event-mediastreamtrack-unmute) event on an already unmuted track (`track.muted == false`).

This seems like a desirable property we should enforce in this spec. Yet we don't in the algorithm we expose, [set a track's muted state](https://w3c.github.io/mediacapture-main/getusermedia.html#set-track-muted) (it allows firing an event regardless of existing state).

We already do so with similar algorithms like [add a track](https://w3c.github.io/mediacapture-main/getusermedia.html#add-track) and [remove a track](https://w3c.github.io/mediacapture-main/getusermedia.html#remove-track), so we probably should here as well.

Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/676 using your GitHub account
Received on Friday, 3 April 2020 21:54:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 3 April 2020 21:54:34 UTC