Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shouldn't fire (un)mute event on already (un)muted track #676

Closed
jan-ivar opened this issue Apr 3, 2020 · 0 comments · Fixed by #685
Closed

Shouldn't fire (un)mute event on already (un)muted track #676

jan-ivar opened this issue Apr 3, 2020 · 0 comments · Fixed by #685
Assignees

Comments

@jan-ivar
Copy link
Member

jan-ivar commented Apr 3, 2020

We shouldn't fire the mute event on an already muted track (track.muted == true).
We shouldn't fire the 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 (it allows firing an event regardless of existing state).

We already do so with similar algorithms like add a track and remove a track, so we probably should here as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant