Convert video-playback* and sources-fallback* tests to testharness.js

Convert video-playback* and sources-fallback* tests to testharness.js

Cleaning up video-playback* and sources-fallback* tests
in media/ to use testharness.js instead of video-test.js.
This will enable to upstream these tests to web-platform-tests.

BUG=588956, 443596
Committed: https://crrev.com/a917ba2f258ec028e8389c4e2141235dcee3d384
Cr-Commit-Position: refs/heads/master@{#407143}

[Srirama, 2016-07-07 15:12:26]

Description was changed from

==========
fix


fix


fix


fix

BUG=
==========

to

==========
Convert video-playback* and sources-fallback* tests to testharness.js

Cleaning up video-playback* and sources-fallback* tests
in media/ to use testharness.js instead of video-test.js. 
This will enable to upstream these tests to web-platform-tests.

BUG=588956
==========

[Srirama, 2016-07-07 15:14:56]

Patchset #1 (id:1) has been deleted

[Srirama, 2016-07-07 15:16:06]

srirama.m@samsung.com changed reviewers:
+ foolip@chromium.org, fs@opera.com

[Srirama, 2016-07-07 15:16:06]

Should we add 443596 to the BUG list? It is marked as won't fix right now.

[fs, 2016-07-07 15:34:57]

On 2016/07/07 at 15:16:06, srirama.m wrote:
> Should we add 443596 to the BUG list? It is marked as won't fix right now.

If this addresses the flakiness, then absolutely (and re-open it too.) The test
is still flaky on Mac it seems.

[fs, 2016-07-07 15:47:49]

lgtm

https://codereview.chromium.org/2121383005/diff/20001/third_party/WebKit/Layo...
File third_party/WebKit/LayoutTests/media/sources-fallback-codecs.html (right):

https://codereview.chromium.org/2121383005/diff/20001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/media/sources-fallback-codecs.html:37: if
(test.setType)
Could use the existence of typeArray instead perhaps?

https://codereview.chromium.org/2121383005/diff/20001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/media/sources-fallback-codecs.html:42:
media.oncanplaythrough = t.step_func_done();
Maybe add onerror handlers to fail fast(er) and to avoid just timing out? (Maybe
the <source> onerror could be kept as well for additional checking.)

[Srirama, 2016-07-07 16:18:53]

Patchset #2 (id:40001) has been deleted

[Srirama, 2016-07-07 16:24:16]

Patchset #2 (id:60001) has been deleted

[Srirama, 2016-07-07 16:30:05]

The flakiness is due to differences in the -expected.txt file, so that should
not be a problem now. I will reopen and close it after sometime if the flakiness
is gone in the flakiness dashboard.

https://codereview.chromium.org/2121383005/diff/20001/third_party/WebKit/Layo...
File third_party/WebKit/LayoutTests/media/sources-fallback-codecs.html (right):

https://codereview.chromium.org/2121383005/diff/20001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/media/sources-fallback-codecs.html:37: if
(test.setType)
On 2016/07/07 15:47:48, fs wrote:
> Could use the existence of typeArray instead perhaps?

Done.

https://codereview.chromium.org/2121383005/diff/20001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/media/sources-fallback-codecs.html:42:
media.oncanplaythrough = t.step_func_done();
On 2016/07/07 15:47:49, fs wrote:
> Maybe add onerror handlers to fail fast(er) and to avoid just timing out?
(Maybe
> the <source> onerror could be kept as well for additional checking.)

Problem is "error" will be fired even for success case because one of "mp4, ogg"
will not be supported.

[fs, 2016-07-07 17:35:59]

On 2016/07/07 at 16:30:05, srirama.m wrote:
> The flakiness is due to differences in the -expected.txt file, so that should
not be a problem now. I will reopen and close it after sometime if the flakiness
is gone in the flakiness dashboard.

Ok. Sounds good.

https://codereview.chromium.org/2121383005/diff/20001/third_party/WebKit/Layo...
File third_party/WebKit/LayoutTests/media/sources-fallback-codecs.html (right):

https://codereview.chromium.org/2121383005/diff/20001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/media/sources-fallback-codecs.html:42:
media.oncanplaythrough = t.step_func_done();
On 2016/07/07 at 16:30:04, Srirama wrote:
> On 2016/07/07 15:47:49, fs wrote:
> > Maybe add onerror handlers to fail fast(er) and to avoid just timing out?
(Maybe
> > the <source> onerror could be kept as well for additional checking.)
> 
> Problem is "error" will be fired even for success case because one of "mp4,
ogg" will not be supported.

Yes. The "old" test double-checked with canPlayType. We can leave that aside if
you think it's more trouble than it is worth.

[Srirama, 2016-07-07 18:29:54]

On 2016/07/07 17:35:59, fs wrote:
> On 2016/07/07 at 16:30:05, srirama.m wrote:
> > The flakiness is due to differences in the -expected.txt file, so that
should
> not be a problem now. I will reopen and close it after sometime if the
flakiness
> is gone in the flakiness dashboard.
> 
> Ok. Sounds good.
> 
>
https://codereview.chromium.org/2121383005/diff/20001/third_party/WebKit/Layo...
> File third_party/WebKit/LayoutTests/media/sources-fallback-codecs.html
(right):
> 
>
https://codereview.chromium.org/2121383005/diff/20001/third_party/WebKit/Layo...
> third_party/WebKit/LayoutTests/media/sources-fallback-codecs.html:42:
> media.oncanplaythrough = t.step_func_done();
> On 2016/07/07 at 16:30:04, Srirama wrote:
> > On 2016/07/07 15:47:49, fs wrote:
> > > Maybe add onerror handlers to fail fast(er) and to avoid just timing out?
> (Maybe
> > > the <source> onerror could be kept as well for additional checking.)
> > 
> > Problem is "error" will be fired even for success case because one of "mp4,
> ogg" will not be supported.
> 
> Yes. The "old" test double-checked with canPlayType. We can leave that aside
if
> you think it's more trouble than it is worth.

Ok, that will be good to have, but it was easy for me to leave it :), so removed
it. Lets see what philip says and if he also feels that it is good to have then
i will try adding it.

[Srirama, 2016-07-13 14:04:03]

On 2016/07/07 18:29:54, Srirama wrote:
> On 2016/07/07 17:35:59, fs wrote:
> > On 2016/07/07 at 16:30:05, srirama.m wrote:
> > > The flakiness is due to differences in the -expected.txt file, so that
> should
> > not be a problem now. I will reopen and close it after sometime if the
> flakiness
> > is gone in the flakiness dashboard.
> > 
> > Ok. Sounds good.
> > 
> >
>
https://codereview.chromium.org/2121383005/diff/20001/third_party/WebKit/Layo...
> > File third_party/WebKit/LayoutTests/media/sources-fallback-codecs.html
> (right):
> > 
> >
>
https://codereview.chromium.org/2121383005/diff/20001/third_party/WebKit/Layo...
> > third_party/WebKit/LayoutTests/media/sources-fallback-codecs.html:42:
> > media.oncanplaythrough = t.step_func_done();
> > On 2016/07/07 at 16:30:04, Srirama wrote:
> > > On 2016/07/07 15:47:49, fs wrote:
> > > > Maybe add onerror handlers to fail fast(er) and to avoid just timing
out?
> > (Maybe
> > > > the <source> onerror could be kept as well for additional checking.)
> > > 
> > > Problem is "error" will be fired even for success case because one of
"mp4,
> > ogg" will not be supported.
> > 
> > Yes. The "old" test double-checked with canPlayType. We can leave that aside
> if
> > you think it's more trouble than it is worth.
> 
> Ok, that will be good to have, but it was easy for me to leave it :), so
removed
> it. Lets see what philip says and if he also feels that it is good to have
then
> i will try adding it.

@foolip, can you please review this once?

[Srirama, 2016-07-19 09:29:57]

Description was changed from

==========
Convert video-playback* and sources-fallback* tests to testharness.js

Cleaning up video-playback* and sources-fallback* tests
in media/ to use testharness.js instead of video-test.js. 
This will enable to upstream these tests to web-platform-tests.

BUG=588956
==========

to

==========
Convert video-playback* and sources-fallback* tests to testharness.js

Cleaning up video-playback* and sources-fallback* tests
in media/ to use testharness.js instead of video-test.js. 
This will enable to upstream these tests to web-platform-tests.

BUG=588956, 443596
==========

[Srirama, 2016-07-19 09:36:56]

On 2016/07/13 14:04:03, Srirama wrote:
> On 2016/07/07 18:29:54, Srirama wrote:
> > On 2016/07/07 17:35:59, fs wrote:
> > > On 2016/07/07 at 16:30:05, srirama.m wrote:
> > > > The flakiness is due to differences in the -expected.txt file, so that
> > should
> > > not be a problem now. I will reopen and close it after sometime if the
> > flakiness
> > > is gone in the flakiness dashboard.
> > > 
> > > Ok. Sounds good.
> > > 
> > >
> >
>
https://codereview.chromium.org/2121383005/diff/20001/third_party/WebKit/Layo...
> > > File third_party/WebKit/LayoutTests/media/sources-fallback-codecs.html
> > (right):
> > > 
> > >
> >
>
https://codereview.chromium.org/2121383005/diff/20001/third_party/WebKit/Layo...
> > > third_party/WebKit/LayoutTests/media/sources-fallback-codecs.html:42:
> > > media.oncanplaythrough = t.step_func_done();
> > > On 2016/07/07 at 16:30:04, Srirama wrote:
> > > > On 2016/07/07 15:47:49, fs wrote:
> > > > > Maybe add onerror handlers to fail fast(er) and to avoid just timing
> out?
> > > (Maybe
> > > > > the <source> onerror could be kept as well for additional checking.)
> > > > 
> > > > Problem is "error" will be fired even for success case because one of
> "mp4,
> > > ogg" will not be supported.
> > > 
> > > Yes. The "old" test double-checked with canPlayType. We can leave that
aside
> > if
> > > you think it's more trouble than it is worth.
> > 
> > Ok, that will be good to have, but it was easy for me to leave it :), so
> removed
> > it. Lets see what philip says and if he also feels that it is good to have
> then
> > i will try adding it.
> 
> @foolip, can you please review this once?

@foolip, one pass through it please (may be you would have missed it)

[foolip, 2016-07-21 00:09:00]

lgtm

https://codereview.chromium.org/2121383005/diff/20001/third_party/WebKit/Layo...
File third_party/WebKit/LayoutTests/media/sources-fallback-codecs.html (right):

https://codereview.chromium.org/2121383005/diff/20001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/media/sources-fallback-codecs.html:42:
media.oncanplaythrough = t.step_func_done();
On 2016/07/07 17:35:59, fs wrote:
> On 2016/07/07 at 16:30:04, Srirama wrote:
> > On 2016/07/07 15:47:49, fs wrote:
> > > Maybe add onerror handlers to fail fast(er) and to avoid just timing out?
> (Maybe
> > > the <source> onerror could be kept as well for additional checking.)
> > 
> > Problem is "error" will be fired even for success case because one of "mp4,
> ogg" will not be supported.
> 
> Yes. The "old" test double-checked with canPlayType. We can leave that aside
if
> you think it's more trouble than it is worth.

Having an error event on the last source element would also work, if you reach
that one you know it's not going to work out.

[Srirama, 2016-07-21 14:28:40]

On 2016/07/21 00:09:00, foolip wrote:
> lgtm
> 
>
https://codereview.chromium.org/2121383005/diff/20001/third_party/WebKit/Layo...
> File third_party/WebKit/LayoutTests/media/sources-fallback-codecs.html
(right):
> 
>
https://codereview.chromium.org/2121383005/diff/20001/third_party/WebKit/Layo...
> third_party/WebKit/LayoutTests/media/sources-fallback-codecs.html:42:
> media.oncanplaythrough = t.step_func_done();
> On 2016/07/07 17:35:59, fs wrote:
> > On 2016/07/07 at 16:30:04, Srirama wrote:
> > > On 2016/07/07 15:47:49, fs wrote:
> > > > Maybe add onerror handlers to fail fast(er) and to avoid just timing
out?
> > (Maybe
> > > > the <source> onerror could be kept as well for additional checking.)
> > > 
> > > Problem is "error" will be fired even for success case because one of
"mp4,
> > ogg" will not be supported.
> > 
> > Yes. The "old" test double-checked with canPlayType. We can leave that aside
> if
> > you think it's more trouble than it is worth.
> 
> Having an error event on the last source element would also work, if you reach
> that one you know it's not going to work out.

That doesn't seem to work, as we are skipping unsupported sources in
selectNextSourceChild()
if (!supportsType(ContentType(type))) {
    goto checkAgain;
}

[Srirama, 2016-07-22 12:31:18]

On 2016/07/21 14:28:40, Srirama wrote:
> On 2016/07/21 00:09:00, foolip wrote:
> > lgtm
> > 
> >
>
https://codereview.chromium.org/2121383005/diff/20001/third_party/WebKit/Layo...
> > File third_party/WebKit/LayoutTests/media/sources-fallback-codecs.html
> (right):
> > 
> >
>
https://codereview.chromium.org/2121383005/diff/20001/third_party/WebKit/Layo...
> > third_party/WebKit/LayoutTests/media/sources-fallback-codecs.html:42:
> > media.oncanplaythrough = t.step_func_done();
> > On 2016/07/07 17:35:59, fs wrote:
> > > On 2016/07/07 at 16:30:04, Srirama wrote:
> > > > On 2016/07/07 15:47:49, fs wrote:
> > > > > Maybe add onerror handlers to fail fast(er) and to avoid just timing
> out?
> > > (Maybe
> > > > > the <source> onerror could be kept as well for additional checking.)
> > > > 
> > > > Problem is "error" will be fired even for success case because one of
> "mp4,
> > > ogg" will not be supported.
> > > 
> > > Yes. The "old" test double-checked with canPlayType. We can leave that
aside
> > if
> > > you think it's more trouble than it is worth.
> > 
> > Having an error event on the last source element would also work, if you
reach
> > that one you know it's not going to work out.
> 
> That doesn't seem to work, as we are skipping unsupported sources in
> selectNextSourceChild()
> if (!supportsType(ContentType(type))) {
>     goto checkAgain;
> }

Sending it to CQ in the current form for now.

[Srirama, 2016-07-22 12:31:26]

The CQ bit was checked by srirama.m@samsung.com

[Srirama, 2016-07-22 12:31:27]

The patchset sent to the CQ was uploaded after l-g-t-m from fs@opera.com
Link to the patchset: https://codereview.chromium.org/2121383005/#ps80001
(title: "rebase and address comments")

[commit-bot: I haz the power, 2016-07-22 12:31:34]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-22 13:36:01]

Description was changed from

==========
Convert video-playback* and sources-fallback* tests to testharness.js

Cleaning up video-playback* and sources-fallback* tests
in media/ to use testharness.js instead of video-test.js. 
This will enable to upstream these tests to web-platform-tests.

BUG=588956, 443596
==========

to

==========
Convert video-playback* and sources-fallback* tests to testharness.js

Cleaning up video-playback* and sources-fallback* tests
in media/ to use testharness.js instead of video-test.js. 
This will enable to upstream these tests to web-platform-tests.

BUG=588956, 443596
==========

[commit-bot: I haz the power, 2016-07-22 13:36:02]

Committed patchset #2 (id:80001)

[commit-bot: I haz the power, 2016-07-22 13:37:52]

Description was changed from

==========
Convert video-playback* and sources-fallback* tests to testharness.js

Cleaning up video-playback* and sources-fallback* tests
in media/ to use testharness.js instead of video-test.js. 
This will enable to upstream these tests to web-platform-tests.

BUG=588956, 443596
==========

to

==========
Convert video-playback* and sources-fallback* tests to testharness.js

Cleaning up video-playback* and sources-fallback* tests
in media/ to use testharness.js instead of video-test.js.
This will enable to upstream these tests to web-platform-tests.

BUG=588956, 443596

Committed: https://crrev.com/a917ba2f258ec028e8389c4e2141235dcee3d384
Cr-Commit-Position: refs/heads/master@{#407143}
==========

[commit-bot: I haz the power, 2016-07-22 13:37:53]

Patchset 2 (id:??) landed as
https://crrev.com/a917ba2f258ec028e8389c4e2141235dcee3d384
Cr-Commit-Position: refs/heads/master@{#407143}