Can't merge PR due to Chrome failing stability check and Firefox just timing out

[birtles]

Despite several retriggers I can't get this build to complete:

https://travis-ci.org/w3c/web-platform-tests/builds/219138173

The Firefox job mostly just sits there saying with no suggesting that it might ever end:

PROCESS | 5824 | MARIONETTE LOG: INFO: Timeout fired

The Chrome job kept failing the stability check although I notice on this latest trigger it is now just doing:

PROCESS | 11743 | Starting ChromeDriver 2.29.461571 (8a88bbe0775e2a23afda0ceaf2ef7ee74e822cc5) on port 4451
PROCESS | 11743 | Only local connections are allowed.
PROCESS | 11860 | Starting ChromeDriver 2.29.461571 (8a88bbe0775e2a23afda0ceaf2ef7ee74e822cc5) on port 4452
PROCESS | 11860 | Only local connections are allowed.
PROCESS | 13137 | Starting ChromeDriver 2.29.461571 (8a88bbe0775e2a23afda0ceaf2ef7ee74e822cc5) on port 4453
PROCESS | 13137 | Only local connections are allowed.
PROCESS | 13255 | Starting ChromeDriver 2.29.461571 (8a88bbe0775e2a23afda0ceaf2ef7ee74e822cc5) on port 4454

I guess it will keep doing that until we run out of integers.

A build from the same PR with nearly the same test content yesterday, however, ran with no problems.

CC: @jugglinmike @bobholt

[birtles]

FWIW, I'm going to rebase the PR and repush to see if that changes anything because I'd really like to land this PR today.

[foolip]

The PR in question is #3330, right?

[birtles]

Yes, that's right

[birtles]

(And it turns out I can't update the PR now. Not sure why. Does it get locked while the travis jobs are running?)

[annevk]

Simple OWNERS change in #5394 is also being blocked.

[frivoal]

Looks like it's not just #5330. Other post-#5330 PRs are being blocked too (e.g. #5370, #5285, #5283) , apparently due to jugglinmike/chrome-screenshot-race#1

[gsnedders]

The Chrome-hanging issue is now #5407, seemingly a bug in ChromeDriver.

@frivoal it probably isn't just that, given many of these aren't reftests, and we've now landed a workaround for that

[gsnedders]

The Firefox issue is #5408.

More generally, I've also filed #5406, #5409, #5410, and #5412.

[jugglinmike]

Just to be clear: this behavior is unrelated to ChromeDriver timeouts. The referenced Chrome job ran to completion and reported a failure due to unstable test results.

[gsnedders]

@jugglinmike uh, I linked to the wrong issue for Chrome. #5408, which is the same issue as with Firefox

[foolip]

Closing this since it hasn't come up since April, perhaps because Chrome failures aren't blocking. @JKereliuk has fixed lots of things in ChromeDriver and there's a new release soon, so any future failures might not be the same anyway.

@lukebjerring at some point we should probably make Chrome failures blocking again, any thoughts on how to track issues like this to be able to enable it with confidence that we won't break everyone's workflows?