Closed
Bug 1049810
Opened 10 years ago
Closed 10 years ago
sharing indicators on the URL bar stay on after each mochitests has finished its execution
Categories
(Core :: WebRTC, defect)
Tracking
()
People
(Reporter: bwc, Assigned: florian)
References
Details
Attachments
(1 file)
(deleted),
patch
|
florian
:
review-
|
Details | Diff | Splinter Review |
While running ./mach mochitest-plain dom/media/tests on OS X, the window sharing indicator stays on after the window sharing tests are done. Unsure whether this is a problem in the test, or the implementation.
Assignee | ||
Comment 2•10 years ago
|
||
There's a bug in the implementation that I'm fixing in bug 1051855.
Assignee | ||
Comment 3•10 years ago
|
||
Could you please confirm that this is now fixed, and if it is, mark as a dup of bug 1051855? Thanks!
Flags: needinfo?(docfaraday)
Reporter | ||
Comment 4•10 years ago
|
||
Seeing the same behavior; once test_peerConnection_basicScreenshare turns the screen-sharing indicator on, it stays on. The same is not true of the test_getUserMedia_basicScreenshare/basicWindowshare tests; the indicator goes away when they complete.
Flags: needinfo?(docfaraday)
Comment 5•10 years ago
|
||
Some more observations:
- the peerConnection test does nothing different for Screen/Window sharing, compared to Audio or Video
- but if you run all mochitests in dom/media/tests/mochitest not a single icon for audio or video shows up during the test run (is that a bug in itself?)
- the only icon which comes up is the screen sharing icon. So that looks like the screen sharing indicator does something different then the microphone and camera icons
- for all of our tests we media.navigator.permission.disabled set to true to disable the permission dialog popping up. Maybe the camera and microphone icons don't show up because of that setting?
Assignee | ||
Comment 6•10 years ago
|
||
(In reply to Nils Ohlmeier [:drno] from comment #5)
My guess would be that the camera/microphone icons don't show up because the tests use fake streams ({fake: true} in the getUserMedia constraints).
Comment 7•10 years ago
|
||
Fist another observations: the share indicators in the Mac shared status bar at the top of the screen (outside of the FF window) go on and off as expected (including the screen sharing one).
(In reply to Florian Quèze [:florian] [:flo] from comment #6)
> My guess would be that the camera/microphone icons don't show up because the
> tests use fake streams ({fake: true} in the getUserMedia constraints).
You guessed correct. I just ran everything with real devices, and then I got so see the share indicators.
So then we should probably turn this into a more general bug of sharing/access indicators in the URL bar not getting turned off during test runs.
Updated•10 years ago
|
Summary: window sharing indicator on the URL bar stays on after the window/screen sharing mochitests are done → sharing indicators on the URL bar stay on after each mochitests has finished its execution
Comment 8•10 years ago
|
||
Attachment #8475523 -
Flags: review?(florian)
Assignee | ||
Comment 9•10 years ago
|
||
Comment on attachment 8475523 [details] [diff] [review]
Stop streams from getUserMedia to stop share indicators
Doesn't look like a bug of the test; if I understand correctly, each mochitest is an HTML page loaded in an iframe. Loading a different page stops all streams, so it should also remove the url bar icons.
Here is another way to reproduce the bug:
1. Load data:text/html,<iframe src="http://queze.net/goinfre/ff_gum_test.html">
2. Click the "Video" button and share the camera
3. See that both the url bar icon and the global indicator are shown.
4. Click the "Main webrtc demo page" link at the top of the page.
Expected result:
Both the url bar icon and the global indicator should be hidden
Actual result:
The global indicator is removed but the url bar icon stays.
Attachment #8475523 -
Flags: review?(florian) → review-
Assignee | ||
Comment 10•10 years ago
|
||
Looking at this closer, I don't think the UI is responsible either. I filed bug 1056172 and attached a patch for what I think is the root cause of the problem.
Updated•10 years ago
|
Flags: qe-verify?
Flags: firefox-backlog+
Updated•10 years ago
|
Flags: qe-verify? → qe-verify+
Assignee | ||
Comment 12•10 years ago
|
||
(In reply to Marco Mucci [:MarcoM] from comment #11)
> Hi Florian, can you provide a point value.
The real patch happened in bug 1056172, so I'll put only 1 point here for the investigation.
Points: --- → 1
Flags: needinfo?(florian)
Reporter | ||
Comment 13•10 years ago
|
||
I can confirm that bug 1056172 has fixed this for me.
Assignee | ||
Comment 14•10 years ago
|
||
Fixed in bug 1056172 per comment 13.
Assignee: nobody → florian
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Updated•10 years ago
|
Iteration: --- → 34.3
Flags: qe-verify+ → qe-verify-
Updated•10 years ago
|
Target Milestone: --- → mozilla34
You need to log in
before you can comment on or make changes to this bug.
Description
•