Byron Campen [:bwc] Reporter
	Description • 10 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.

	Florian Quèze [:florian] Assignee
	Comment 2 • 10 years ago

There's a bug in the implementation that I'm fixing in bug 1051855.

	Florian Quèze [:florian] 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!

	Byron Campen [:bwc] 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.

	Nils Ohlmeier [:drno]
	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?

	Florian Quèze [:florian] 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).

	Nils Ohlmeier [:drno]
	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.

	Nils Ohlmeier [:drno]
	Comment 8 • 10 years ago

Try run: https://tbpl.mozilla.org/?tree=Try&rev=b2eeb5a0b01a

	Florian Quèze [: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.

	Florian Quèze [:florian] 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.

	Marco Mucci [:MarcoM]
	Comment 11 • 10 years ago

Hi Florian, can you provide a point value.

	Florian Quèze [:florian] 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.

	Byron Campen [:bwc] Reporter
	Comment 13 • 10 years ago

I can confirm that bug 1056172 has fixed this for me.

	Florian Quèze [:florian] Assignee
	Comment 14 • 10 years ago

Fixed in bug 1056172 per comment 13.