1421724 - browser_devices_get_user_media_screen.js consistently timing out in ccov builds

Status: RESOLVED FIXED

(Core :: WebRTC, enhancement, P3)

Comment 1

[Marco Castelluccio [:marco]]

Increasing the timeout by 10x didn't help.

Comment 2

[Marco Castelluccio [:marco]]

Attachment: Disable test until it is fixed

Let's disable the test until it is fixed.

Comment 3

[Alex Chronopoulos [:achronop]]

Comment on attachment 8933336 [details] [diff] [review]
Disable test until it is fixed

If I understand correctly we disable only for Code Coverage run in windows.

Comment 4

[Marco Castelluccio [:marco]]

(In reply to Alex Chronopoulos [:achronop] from comment #3)
> Comment on attachment 8933336 [details] [diff] [review]
> Disable test until it is fixed
> 
> If I understand correctly we disable only for Code Coverage run in windows.

Exactly.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/ac74d02ba092
Disable browser_devices_get_user_media_screen.js on Windows coverage builds until it is fixed. r=achronop

Comment 6

[Andrei Ciure[:aciure]]

https://hg.mozilla.org/mozilla-central/rev/ac74d02ba092

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The leave-open keyword is there and there is no activity for 6 months.
:drno, maybe it's time to close this bug?

Comment 8

[Andreas Pehrson [:pehrsons]]

I hit a similar issue in a local linux headless test run. Turns out that we're timing out at [1] waiting for the doorhanger to appear, but it doesn't because the right window is not active any longer. chrome://browser/content/webrtcIndicator.xul is the active window instead (this is the global media capture indicator on at least linux, but not mac, hopefully windows too).

This makes sense perhaps, as it has appeared after the previous doorhanger was granted permission but before the current one could appear.

Florian, do you know whether this is expected? I.e., should I make the test move focus to the previous window, or do we expect the webrtc indicator to not take focus?


[1] https://searchfox.org/mozilla-central/rev/0ee0b63732d35d16ba22d5a1120622e2e8d58c29/browser/base/content/test/webrtc/browser_devices_get_user_media_screen.js#107-110

Comment 9

[Florian Quèze [:florian]]

(In reply to Andreas Pehrson [:pehrsons] from comment #8)

> Florian, do you know whether this is expected? I.e., should I make the test
> move focus to the previous window, or do we expect the webrtc indicator to
> not take focus?

I don't expect the webrtc global indicator window to steal focus. That said, if forcefully moving the focus to the browser window again makes the test pass and lets you move forward, I'm ok with it.

Comment 10

[Andreas Pehrson [:pehrsons]]

Attachment: Bug 1421724 - Re-enable browser-chrome gUM_screen test. r?marco

Comment 11

[Andreas Pehrson [:pehrsons]]

Attachment: Bug 1421724 - Steal back focus from global webrtc indicator when doing second gUM requests. r?florian

Comment 12

[Andreas Pehrson [:pehrsons]]

Attachment: Bug 1421724 - Account for headless Firefox not exposing scary windows. r?florian

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5c37c61c937e
Re-enable browser-chrome gUM_screen test. r=marco
https://hg.mozilla.org/integration/autoland/rev/2c1444bc6c19
Steal back focus from global webrtc indicator when doing second gUM requests. r=florian
https://hg.mozilla.org/integration/autoland/rev/2c87990aee06
Account for headless Firefox not exposing scary windows. r=florian

Comment 14

[Oana Pop-Rus]

https://hg.mozilla.org/mozilla-central/rev/5c37c61c937e
https://hg.mozilla.org/mozilla-central/rev/2c1444bc6c19
https://hg.mozilla.org/mozilla-central/rev/2c87990aee06