Increase the timeout for media element activation tests

Increase the timeout for media element activation tests

The async tests wait for the canplay event (HAVE_FUTURE_DATA) which
depends on the network. 10 seconds should be enough.

BUG=355489

[acolwell GONE FROM CHROMIUM, 2014-03-25 22:57:55]

https://codereview.chromium.org/209383013/diff/1/LayoutTests/media/activation...
File LayoutTests/media/activation-behavior.html (right):

https://codereview.chromium.org/209383013/diff/1/LayoutTests/media/activation...
LayoutTests/media/activation-behavior.html:8: setup({ timeout: 10000 });
It would be nice to make this and the ones below the default for all our media
based w3c tests so we don't have to sprinkle these around various tests. WDYT?

[philipj_slow, 2014-03-26 09:06:42]

Dirk, do you have any ideas for how to solve this generally?

https://codereview.chromium.org/209383013/diff/1/LayoutTests/media/activation...
File LayoutTests/media/activation-behavior.html (right):

https://codereview.chromium.org/209383013/diff/1/LayoutTests/media/activation...
LayoutTests/media/activation-behavior.html:8: setup({ timeout: 10000 });
On 2014/03/25 22:57:55, acolwell wrote:
> It would be nice to make this and the ones below the default for all our media
> based w3c tests so we don't have to sprinkle these around various tests. WDYT?

Yeah, it would be nice if the default timeouts as in "Regular timeout: 18000,
slow test timeout: 90000" were the defaults for testharness.js as well.
Unfortunately, these two kinds of timeouts appear fundamentally different.
Regular LayoutTests have a timeout in the Python runner, the _handle_timeout()
in server_process.py being the most low-level bits I can find. testharness.js
has timeouts internally...

I don't know how to make these two blend. A quickfix would be to just change the
defaults in testharness.js to some ridiculously high value so that it's always
the Python timeout that happens first.

Any other ideas?

[acolwell GONE FROM CHROMIUM, 2014-03-26 16:37:05]

On 2014/03/26 09:06:42, philipj wrote:
> Dirk, do you have any ideas for how to solve this generally?
> 
>
https://codereview.chromium.org/209383013/diff/1/LayoutTests/media/activation...
> File LayoutTests/media/activation-behavior.html (right):
> 
>
https://codereview.chromium.org/209383013/diff/1/LayoutTests/media/activation...
> LayoutTests/media/activation-behavior.html:8: setup({ timeout: 10000 });
> On 2014/03/25 22:57:55, acolwell wrote:
> > It would be nice to make this and the ones below the default for all our
media
> > based w3c tests so we don't have to sprinkle these around various tests.
WDYT?
> 
> Yeah, it would be nice if the default timeouts as in "Regular timeout: 18000,
> slow test timeout: 90000" were the defaults for testharness.js as well.
> Unfortunately, these two kinds of timeouts appear fundamentally different.
> Regular LayoutTests have a timeout in the Python runner, the _handle_timeout()
> in server_process.py being the most low-level bits I can find. testharness.js
> has timeouts internally...
> 
> I don't know how to make these two blend. A quickfix would be to just change
the
> defaults in testharness.js to some ridiculously high value so that it's always
> the Python timeout that happens first.
> 
> Any other ideas?

I believe we should just make the timeouts >= than the LayoutTest harness values
and rely on the LayoutTest harness timeout logic. I believe we already have
local edits to the testharness.js, ISTM that modifying the timeouts would be a
pretty trivial edit to maintain.

[philipj_slow, 2014-03-26 17:23:45]

OK, let's try https://codereview.chromium.org/213283002/ instead.