Florian, Marco -- We want to fix this for screensharing in Fx 33. Can one of you move this to the Firefox backlog and ask for it to be prioritized?
Component: WebRTC: Audio/Video → General
Product: Core → Firefox
Version: 34 Branch → 33 Branch
This is enough to fix the bug as reported, but code inspection shows that there are variations of the same bug.
Assignee: nobody → florian
Status: NEW → ASSIGNED
I modified http://queze.net/goinfre/ff_gum_test.html a bit to test this (added the 3 buttons that contain the word "then"). I think this covers all cases and makes the code a bit less fragile.
Comment on attachment 8472644 [details] [diff] [review] Patch v2 Review of attachment 8472644 [details] [diff] [review]: ----------------------------------------------------------------- ::: browser/modules/webrtcUI.jsm @@ +664,5 @@ > + let notification = > + chromeWin.PopupNotifications.getNotification("webRTC-sharingDevices", aBrowser); > + if (notification) > + chromeWin.PopupNotifications.remove(notification); > + } This and the next block are pretty similar... not sure if it doesn't make sense to try and unify them rather than duplicate what is essentially identical code. OTOH, can't think of a good way to do that, and it's only a few lines, so meh.
Attachment #8472644 - Flags: review?(gijskruitbosch+bugs) → review+
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 34
Iteration: 34.2 → 34.3
QA Whiteboard: [qa+]
Reproduced bug on Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0 Verified fix on Mozilla/5.0 (X11; Linux x86_64; rv:34.0) Gecko/20100101 Firefox/34.0 Awaiting confirmation in another platform.
QA Whiteboard: [bugday-20140820]
OS: Windows 7 → All
I've reproduced the original issue on fippo.github.io/webrtc-landing/gum_test_fippo3.html (comment 0) and http://queze.net/goinfre/ff_gum_test.html (comment 3), using Nightly from August 11 on Windows 7 x64. On http://queze.net/goinfre/ff_gum_test.html, I saw the issue for the following cases: - Video then Window * when using video.mozSrcObject.stop() - Window then Video * when using video.mozSrcObject.stop() * when using localVideo.mozSrcObject.stop() - Audio then Video - no issue In all cases the Video or Screen sharing icon was removed from the sharing indicator, but not from the address bar. The steps to reproduce were: - ensured media.getusermedia.screensharing.enabled = true (on by default on 34 Nightly now) - set media.getusermedia.screensharing.allowed_domains = "fippo.github.io" or "queze.net" - opened fippo.github.io/webrtc-landing/gum_test_fippo3.html or http://queze.net/goinfre/ff_gum_test.html - started Window (fippo.github.io) or Video then Window / Window then Video / Audio then Video (queze.net) - closed the streams using thestream.stop() (for fippo.github.io) or video.mozSrcObject.stop()/localVideo.mozSrcObject.stop() in different order (for queze.net) Using the latest Nightly (BuildID=20140820030202) on Win 7 x64 and Mac OS X 10.9.4, I got no more issues: the Video/Screen sharing icon was removed from both the sharing indicator and the address bar within 1-2 seconds.
Comment on attachment 8472644 [details] [diff] [review] Patch v2 Approval Request Comment [Feature/regressing bug #]: bug 1037405 [User impact if declined]: Screensharing icons may stay in the URL bar even after the stream has been stopped, and confuse the user. [Describe test coverage new/current, TBPL]: In m-c, verified by QA. [Risks and why]: low. [String/UUID change made/needed]: none.
Attachment #8472644 - Flags: approval-mozilla-aurora?
5 years ago
5 years ago
Attachment #8472644 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Verified in latest Firefox 33 Aurora (BuildID=20140827004002) on Windows 7 x64, Mac OS X 10.8.5 and Ubuntu 13.04 x64. I tested the same things as in comment 8, with no issues encountered.
You need to log in before you can comment on or make changes to this bug.