sharing indicators on the URL bar stay on after each mochitests has finished its execution

RESOLVED FIXED in mozilla34

Status

()

Core
WebRTC
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: bwc, Assigned: florian)

Tracking

Trunk
mozilla34
x86
Mac OS X
Points:
1
Dependency tree / graph
Bug Flags:
firefox-backlog +
qe-verify -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
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.

Updated

4 years ago
Duplicate of this bug: 1050914
There's a bug in the implementation that I'm fixing in bug 1051855.
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

4 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)
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?
(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).
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

4 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
Created attachment 8475523 [details] [diff] [review]
Stop streams from getUserMedia to stop share indicators

Try run: https://tbpl.mozilla.org/?tree=Try&rev=b2eeb5a0b01a
Attachment #8475523 - Flags: review?(florian)
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-
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

4 years ago
Flags: qe-verify?
Flags: firefox-backlog+

Updated

4 years ago
Flags: qe-verify? → qe-verify+
Hi Florian, can you provide a point value.
Flags: needinfo?(florian)
(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

4 years ago
I can confirm that bug 1056172 has fixed this for me.
Fixed in bug 1056172 per comment 13.
Assignee: nobody → florian
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED

Updated

4 years ago
Iteration: --- → 34.3
Flags: qe-verify+ → qe-verify-
Target Milestone: --- → mozilla34
You need to log in before you can comment on or make changes to this bug.