1290854 - Intermittent TEST-UNEXPECTED-TIMEOUT | /mediacapture-streams/GUM-unknownkey-option-param.https.html | expected OK

Status: RESOLVED WORKSFORME

(Testing :: web-platform-tests, defect, P3)

Description

[Treeherder Bug Filer]

Filed by: tomcat [at] mozilla.com

https://treeherder.mozilla.org/logviewer.html#?job_id=33003662&repo=mozilla-inbound

http://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-inbound-macosx64/1470035963/mozilla-inbound_yosemite_r7_test-web-platform-tests-e10s-3-bm108-tests1-macosx-build2098.txt.gz

Comment 1

[Byron Campen [:bwc]]

Any idea what might be going on here? I don't see any useful output in the log.

Comment 2

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

I have no idea why this would time out, but I also have no idea how these tests can work. They look outdated and wrong [1]:

>  assert_throws(
>      "NOT_SUPPORTED_ERR",
>      function () {
>        navigator.getUserMedia(
>            {doesnotexist:true},
>            t.step_func(function (stream) {
>              assert_unreached("This should never be triggered since the constraints parameter is unrecognized");
>            }), t.step_func(function (error) {
>              assert_unreached("This should never be triggered since the constraints parameter is unrecognized");
>            }));
>      }
>  )

AFAIK navigator.getUserMedia({doesnotexist:true}) should not throw at all, but fire the failure callback, so wth?

[1] https://dxr.mozilla.org/mozilla-central/rev/331c4166a3a2df2d3a037107addef5d85cdc31b5/testing/web-platform/tests/mediacapture-streams/GUM-unknownkey-option-param.https.html#20-30

Comment 3

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Actually, navigator.getUserMedia should throw a TypeError since we only implement navigator.mozGetUserMedia...

Comment 4

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

nm, I see there's a vendor prefix thing going on. Still, it shouldn't throw.

Comment 5

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Ok, I remember now, lots of these webplatform tests are allowed to fail, but still exercise the code, so please excuse my catching up.

The only thing I can think of is that with bug 1213517 landed, we're handling concurrent constraints for gUM differently, and a lot of these tests (the ones that succeed anyway) fire off gUM calls without ever stopping the resulting streams, meaning they're effectively concurrent requests (which they probably shouldn't be since having tests depend on tests that ran before and garbage collection is usually a bad idea, so they should probably be re-written, which we should file an issue on with the spec people).

So it's possible a combination of these tests end up altering the settings of the camera when it is already running, which we previously disallowed, but now this ends up restarting the camera, which is new code, and that could be where it hangs, possibly.

Gcp, does this sound plausible?

[1] https://hg.mozilla.org/mozilla-central/annotate/331c4166a3a2df2d3a037107addef5d85cdc31b5/testing/web-platform/meta/mediacapture-streams/GUM-unknownkey-option-param.https.html.ini#l4

Comment 6

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Or it could totally be related to the 100+ other TEST-UNEXPECTED-TIMEOUT bugs filed just since Monday...

https://bugzilla.mozilla.org/buglist.cgi?quicksearch=web-platform-tests

Comment 7

[Gian-Carlo Pascutto [:gcp]]

I've only written the Android tests, so I have no idea if what you describe is correct for the others or not.

Comment 8

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Tracked in bug 1291234; will likely never happen again in this test.