Closed Bug 1049810 Opened 6 years ago Closed 6 years ago

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

Categories

(Core :: WebRTC, defect)

x86
macOS
defect
Not set
Points:
1

Tracking

()

RESOLVED FIXED
mozilla34
Iteration:
34.3

People

(Reporter: bwc, Assigned: florian)

References

Details

Attachments

(1 file)

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.
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)
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.
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 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-
Depends on: 1056172
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.
Flags: qe-verify?
Flags: firefox-backlog+
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)
I can confirm that bug 1056172 has fixed this for me.
Fixed in bug 1056172 per comment 13.
Assignee: nobody → florian
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
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.