Closed Bug 1463581 Opened 7 years ago Closed 6 years ago

Stopping a live gUM track doesn't update the aggregated track.enabled state across track clones

Categories

(Core :: WebRTC: Audio/Video, defect, P2)

60 Branch
defect

Tracking

()

VERIFIED FIXED
mozilla62
Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 61+ verified
firefox60 --- wontfix
firefox61 + verified
firefox62 + verified

People

(Reporter: jib, Assigned: pehrsons)

References

Details

(Keywords: regression)

Attachments

(2 files)

As of bug 1299515 we turn off cam/mic on track.enabled = false. However, there's a bug if you're using track.clone(), where this doesn't happen correctly. E.g. if you do: let copy = videoTrack.clone(); copy.enabled = false; videoTrack.stop(); and hold on to `copy`, the camera should mute, its light extinguish, and the browser's blinking red indicator should switch to solid gray. Instead, the light and blinking red indicator stay on. STR: 1. Open https://jsfiddle.net/jib1/gphjq1ta/ 2. Give one-time camera permission (leave "remember this decision" unchecked). 3. Click [Begin], [End], [Begin], [End] Expected result: No second permission prompt, and light goes out after each [End]. Expected result: No second permission prompt, and light stays on. Workaround: 3. Click [Begin], [Mute video], [End], [Begin], [End]
[Tracking Requested - why for this release]: Unfortunate flaw in new 60 privacy feature. Has a workaround though.
Typo: the second "Expected result:" should be "Actual result:"
Status: NEW → ASSIGNED
Comment on attachment 8981905 [details] Bug 1463581 - Signal enabled state changes also on UnregisterSink. https://reviewboard.mozilla.org/r/247924/#review254288 lgtm
Attachment #8981905 - Flags: review?(jib) → review+
Comment on attachment 8981904 [details] Bug 1463581 - Add browser chrome test. https://reviewboard.mozilla.org/r/247922/#review254390 ::: browser/base/content/test/webrtc/browser_devices_get_user_media_paused.js:42 (Diff revision 1) > + .forEach(t => t.stop()); > + } > + if (args.video != null) { > + clones.filter(t => t.kind == "video") > + .forEach(t => t.stop()); > + } should you maybe clear the gClones list in this function?
Attachment #8981904 - Flags: review?(jhofmann) → review+
Pushed by pehrsons@gmail.com: https://hg.mozilla.org/integration/autoland/rev/4931c4cb7c74 Add browser chrome test. r=johannh https://hg.mozilla.org/integration/autoland/rev/d42b5abd0201 Signal enabled state changes also on UnregisterSink. r=jib
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla62
What kind of testing/verification does this need before we consider it for uplift?
Flags: needinfo?(apehrson)
IMO the added browser chrome test is sufficient because of the simplicity of the fix. If anyone insists on manual verification we should test that 1) the symptoms are gone per the STR in comment 0, and 2) that it didn't regress any existing behavior. The latter should be covered by the original PI-request for beta which I don't think has taken place yet.
Flags: needinfo?(apehrson)
Comment on attachment 8981905 [details] Bug 1463581 - Signal enabled state changes also on UnregisterSink. [Approval Request Comment] If this is not a sec:{high,crit} bug, please state case for ESR consideration: - This can in some cases leave the camera (both hw light and browser chrome) on even though the application disabled it. This can fool users into thinking the application is snooping on them. User impact if declined: - See above Fix Landed on Version: - 62 Risk to taking this patch (and alternatives if risky): - Very low String or UUID changes made by this patch: - None See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info. Approval Request Comment [Feature/Bug causing the regression]: - bug 1299515 (60) [User impact if declined]: - See above [Is this code covered by automated tests?]: - Yes [Has the fix been verified in Nightly?]: - I just tested and it looks good [Needs manual test from QE? If yes, steps to reproduce]: - No, covered by automation [List of other uplifts needed for the feature/fix]: - None [Is the change risky?]: - No [Why is the change risky/not risky?]: - Trivial fix [String changes made/needed]: - None
Attachment #8981905 - Flags: approval-mozilla-esr60?
Attachment #8981905 - Flags: approval-mozilla-beta?
Flags: qe-verify+
Comment on attachment 8981905 [details] Bug 1463581 - Signal enabled state changes also on UnregisterSink. Makes sure that the hardware indicators reflect the actual state of things. Thanks for including an automated test! Approved for 61.0b12 and ESR 60.1.
Attachment #8981905 - Flags: approval-mozilla-esr60?
Attachment #8981905 - Flags: approval-mozilla-esr60+
Attachment #8981905 - Flags: approval-mozilla-beta?
Attachment #8981905 - Flags: approval-mozilla-beta+
Build ID: 20180605220158 User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0 Verified as fixed on Firefox Nightly 62.0a1 on Windows 10 x 64, Windows 7 x32, Mac OS X 10.12 and Ubuntu 18.04 x64.
Build ID: 20180607135512 User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0 Verified as fixed on Firefox 61.0b12 and on on Firefox ESR on a build from "https://treeherder.mozilla.org/#/jobs?repo=mozilla-esr60&fromchange=efbcc205a0d3562691bf62bb0cb55bb7e891e8ff&selectedJob=182024831" on Windows 10 x 64, Windows 7 x32, Mac OS X 10.12 and Ubuntu 18.04 x64.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: