Failed once today with Nightly en-US, on mm-osx-106-2. Line affected: http://hg.mozilla.org/qa/mozmill-tests/file/default/firefox/tests/endurance/testVideo_OGVBuffering/test1.js#l44 Will keep an eye if it happens again.

Failed several times more, all on OS X different versions. It didn't reproduce locally by running just this test on a patched repository, with 10 iterations and entities. I will prepare a skip patch and connect to a machine to see if I can figure out what's happening when running this test.

Which versions of OS X are affected? Do we have a problem accessing mozqa.com? Can you reproduce on one of those affected machines? This is Nightly only?

There are a couple of media (video) related code changes since yesterday. It may be a regression.

It failed once on each version, 10.6, 10.7, 10.8 and 10.9 I tried to reproduce on 10.9. Nightly only so far.

I'll look for the regression, I was able to reproduce on a remote machine. Also I have to check if other branches are affected.

Comment on attachment 8400696 [details] [diff] [review] skip patch Review of attachment 8400696 [details] [diff] [review]: ----------------------------------------------------------------- Disabled: http://hg.mozilla.org/qa/mozmill-tests/rev/d86a0b697d8d (default)

Here is the regression range : https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=734e0f2b5083&tochange=0ff6afce0133 Most likely bug 778077 is the reason. I'll look for a fix.

Daniel, this is not a finished regression test. As Andreea mentioned to me yesterday, you are running inbound builds to narrow down the range. I don't see that here. Please make sure to test this, and also mark the bug appropriately, and add the necessary dependency.

Reduced the regression range using inbound tinderbox build to this pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=b4edb59d3db5&tochange=35180f110e44 I'm currently not sure if bug 631058 or bug 778077 is the cause for this. Maybe Chris Pearce can help us with this and tell how can we test now that video data is ready to play, given that testing the readyState of the element being equal with HAVE_ENOUGH_DATA don't seem to work anymore.

Andreea, was this only affected OS X or all platforms?

On all, we skipped it quickly and when was filed only OS X have ran. Linux report: http://mozmill-daily.blargon7.com/#/endurance/report/eeab4d15c588c5e6f00ab97aa57a1960 Windows: http://mozmill-daily.blargon7.com/#/endurance/report/eeab4d15c588c5e6f00ab97aa57b4d2e

Set the "preload" attribute on the <video> to "auto". e.g.: <video preload="auto" ... ></video>

Bug 993308 was fixed so now this test runs fine. We can unskip this test. http://mozmill-crowd.blargon7.com/#/endurance/report/7ab760e27012969ae02e3b9e412d57e6

Enabled, no need for the patch, I just backed out the skip: http://hg.mozilla.org/qa/mozmill-tests/rev/1c59d5fed801