The timing of this suggests a possible regression from bug 1154881, but I'm a bit confused how that would be. We'll see if they show on on Aurora too with that patch having been uplifted there already. 03:49:02 INFO - TEST-START | /media-source/mediasource-redundant-seek.html 03:49:02 INFO - PROCESS | 4434 | WARNING: content window passed to PrivateBrowsingUtils.isWindowPrivate. Use isContentWindowPrivate instead (but only for frame scripts). 03:49:02 INFO - PROCESS | 4434 | pbu_isWindowPrivate@resource://gre/modules/PrivateBrowsingUtils.jsm:25:14 03:49:02 INFO - PROCESS | 4434 | nsBrowserAccess.prototype.openURI@chrome://browser/content/browser.js:15621:21 03:49:02 INFO - PROCESS | 4434 | __marionetteFunc@dummy file:19:30 03:49:02 INFO - PROCESS | 4434 | @dummy file:28:3 03:49:02 INFO - PROCESS | 4434 | executeWithCallback@chrome://marionette/content/listener.js:754:5 03:49:02 INFO - PROCESS | 4434 | executeAsyncScript@chrome://marionette/content/listener.js:650:3 03:50:02 INFO - PROCESS | 4434 | MARIONETTE LOG: INFO: Timeout fired 03:50:02 INFO - TEST-UNEXPECTED-TIMEOUT | /media-source/mediasource-redundant-seek.html | expected OK 03:50:02 INFO - TEST-INFO took 60315ms

will disable this test on linux (as it is disabled on windows).

Disable test on win7. Results is intermittent, was expecting timeout but sometimes succeeded ; on linux was expecting OK but sometimes got timeout.

Comment on attachment 8607278 [details] [diff] [review] Disable test on XP/Linux for intermittent failures >- expected: >- if not debug and (os == "win") and (version == "5.1.2600") and (processor == "x86") and (bits == 32): TIMEOUT >+ disabled: >+ if (os == "win") and (version == "5.1.2600"): https://bugzilla.mozilla.org/show_bug.cgi?id=1165938 >+ if os == "linux": https://bugzilla.mozilla.org/show_bug.cgi?id=1165938 Please just link to bug 1154881 as that has the reason for the intermittent. "disabled" on a subtest as in https://hg.mozilla.org/mozilla-central/rev/cb3a80b78c0b just ignores the result. However, a timeout in a subtest also causes a timeout in a parent, so if there is an intermittent timeout in a subtest, then the parent needs to also be disabled, and none of the test will run.

(In reply to Karl Tomlinson (ni?:karlt) from comment #14) > Comment on attachment 8607278 [details] [diff] [review] > Disable test on XP/Linux for intermittent failures > > >- expected: > >- if not debug and (os == "win") and (version == "5.1.2600") and (processor == "x86") and (bits == 32): TIMEOUT > >+ disabled: > >+ if (os == "win") and (version == "5.1.2600"): https://bugzilla.mozilla.org/show_bug.cgi?id=1165938 > >+ if os == "linux": https://bugzilla.mozilla.org/show_bug.cgi?id=1165938 > > Please just link to bug 1154881 as that has the reason for the intermittent. no, this is a different reason for failure. the timeupdate being received in place of seeking doesn't cause a timeout, it causes a failure. I can't explain the why with this one (yet) > > "disabled" on a subtest as in > https://hg.mozilla.org/mozilla-central/rev/cb3a80b78c0b just ignores the > result. However, a timeout in a subtest also causes a timeout in a parent, > so if there is an intermittent timeout in a subtest, then the parent needs > to also be disabled, and none of the test will run. this is what I did, the whole test (e.g. the parent) is disabled for precisely that reason.