Mark HTMLMediaElement media tracks functionality as stable

Mark HTMLMediaElement media tracks functionality as stable

This will make HTMLMediaElement media tracks accessible and usable
by default, without enable-experimental-web-platform-features flag.
Intent to ship notification:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/Yk8u329AmIs

BUG=249427, 249428

[servolk, 2016-08-16 17:33:23]

The CQ bit was checked by servolk@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-16 17:33:37]

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

[servolk, 2016-08-16 18:30:57]

The CQ bit was checked by servolk@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-16 18:31:04]

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

[servolk, 2016-08-16 18:43:58]

Description was changed from

==========
Enable media tracks functionality by default

Currently media tracks are behind the experimental flag and are not
available by default. This change will remove the flag and will make
media tracks accessible by default.

BUG=249427,249428
==========

to

==========
Enable media tracks functionality by default

Currently media tracks are behind the experimental flag and are not
available by default. This change will remove the flag and will make
media tracks accessible by default.

BUG=249427,249428
==========

[servolk, 2016-08-16 18:43:59]

servolk@chromium.org changed reviewers:
+ foolip@chromium.org, mlamouri@chromium.org, wolenetz@chromium.org

[commit-bot: I haz the power, 2016-08-16 21:18:17]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-16 21:18:19]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[servolk, 2016-08-17 00:04:23]

The CQ bit was checked by servolk@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-17 00:05:05]

Dry run: 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-08-17 01:38:18]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-17 01:38:19]

Dry run: This issue passed the CQ dry run.

[servolk, 2016-08-17 02:20:01]

The CQ bit was checked by servolk@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-17 02:20:24]

Dry run: 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-08-17 04:13:10]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-17 04:13:11]

Dry run: This issue passed the CQ dry run.

[mlamouri (slow - plz ping), 2016-08-17 09:09:39]

https://codereview.chromium.org/2249763003/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/platform/RuntimeEnabledFeatures.in (left):

https://codereview.chromium.org/2249763003/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/platform/RuntimeEnabledFeatures.in:33:
AudioVideoTracks status=experimental
Usually, we mark the status as "stable" for a release or two before removing the
flag entirely. Is there a reason I'm missing why you prefer to drop the flag?

[servolk, 2016-08-17 15:56:22]

https://codereview.chromium.org/2249763003/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/platform/RuntimeEnabledFeatures.in (left):

https://codereview.chromium.org/2249763003/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/platform/RuntimeEnabledFeatures.in:33:
AudioVideoTracks status=experimental
On 2016/08/17 09:09:39, Mounir Lamouri wrote:
> Usually, we mark the status as "stable" for a release or two before removing
the
> flag entirely. Is there a reason I'm missing why you prefer to drop the flag?

No reason, I just have no prior experience with moving features to stable and
based on the comment at line 17 above, which says '... stable features should be
rare ...' I've thought it would be better to remove the flag entirely, since
there are few places that need to be updated (I believe I got every single place
that need to be updated in this CL) and so it would be easy to remove. I can
mark the feature as 'stable' for now if that's the preferred way.

[wolenetz, 2016-08-18 00:10:50]

https://codereview.chromium.org/2249763003/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/platform/RuntimeEnabledFeatures.in (left):

https://codereview.chromium.org/2249763003/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/platform/RuntimeEnabledFeatures.in:33:
AudioVideoTracks status=experimental
On 2016/08/17 15:56:22, servolk wrote:
> On 2016/08/17 09:09:39, Mounir Lamouri wrote:
> > Usually, we mark the status as "stable" for a release or two before removing
> the
> > flag entirely. Is there a reason I'm missing why you prefer to drop the
flag?
> 
> No reason, I just have no prior experience with moving features to stable and
> based on the comment at line 17 above, which says '... stable features should
be
> rare ...' I've thought it would be better to remove the flag entirely, since
> there are few places that need to be updated (I believe I got every single
place
> that need to be updated in this CL) and so it would be easy to remove. I can
> mark the feature as 'stable' for now if that's the preferred way.

+1 to marking stable rather than ripping all the gates out.
Note that I'm investigating an MSE audio/videoTrack-related w3c test suite
failure at the moment (it looks like we need to fire 'change' at
{audio,video}Tracks when selected/enabled track changes. Or maybe the new test
suite test is doing something wrong. I'll fix one or both of Chromium and w3c
test suite shortly. Late changes like what I'll probably need to do further
justify marking 'stable' instead of ripping out the gates.

[wolenetz, 2016-08-18 00:12:42]

On 2016/08/18 00:10:50, wolenetz wrote:
>
https://codereview.chromium.org/2249763003/diff/40001/third_party/WebKit/Sour...
> File third_party/WebKit/Source/platform/RuntimeEnabledFeatures.in (left):
> 
>
https://codereview.chromium.org/2249763003/diff/40001/third_party/WebKit/Sour...
> third_party/WebKit/Source/platform/RuntimeEnabledFeatures.in:33:
> AudioVideoTracks status=experimental
> On 2016/08/17 15:56:22, servolk wrote:
> > On 2016/08/17 09:09:39, Mounir Lamouri wrote:
> > > Usually, we mark the status as "stable" for a release or two before
removing
> > the
> > > flag entirely. Is there a reason I'm missing why you prefer to drop the
> flag?
> > 
> > No reason, I just have no prior experience with moving features to stable
and
> > based on the comment at line 17 above, which says '... stable features
should
> be
> > rare ...' I've thought it would be better to remove the flag entirely, since
> > there are few places that need to be updated (I believe I got every single
> place
> > that need to be updated in this CL) and so it would be easy to remove. I can
> > mark the feature as 'stable' for now if that's the preferred way.
> 
> +1 to marking stable rather than ripping all the gates out.
> Note that I'm investigating an MSE audio/videoTrack-related w3c test suite
> failure at the moment (it looks like we need to fire 'change' at
> {audio,video}Tracks when selected/enabled track changes. Or maybe the new test
> suite test is doing something wrong. I'll fix one or both of Chromium and w3c
> test suite shortly. Late changes like what I'll probably need to do further
> justify marking 'stable' instead of ripping out the gates.

Note: The failing w3c tests are within
https://github.com/w3c/web-platform-tests/pull/3182.

[servolk, 2016-08-18 02:17:22]

Description was changed from

==========
Enable media tracks functionality by default

Currently media tracks are behind the experimental flag and are not
available by default. This change will remove the flag and will make
media tracks accessible by default.

BUG=249427,249428
==========

to

==========
Mark HTMLMediaElement media tracks functionality as stable

This will make HTMLMediaElement media tracks accessible and usable
by default, without enable-experimental-web-platform-features flag.

BUG=249427,249428
==========

[servolk, 2016-08-18 02:17:37]

The CQ bit was checked by servolk@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-18 02:17:57]

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

[servolk, 2016-08-18 02:18:04]

On 2016/08/18 00:12:42, wolenetz wrote:
> On 2016/08/18 00:10:50, wolenetz wrote:
> >
>
https://codereview.chromium.org/2249763003/diff/40001/third_party/WebKit/Sour...
> > File third_party/WebKit/Source/platform/RuntimeEnabledFeatures.in (left):
> > 
> >
>
https://codereview.chromium.org/2249763003/diff/40001/third_party/WebKit/Sour...
> > third_party/WebKit/Source/platform/RuntimeEnabledFeatures.in:33:
> > AudioVideoTracks status=experimental
> > On 2016/08/17 15:56:22, servolk wrote:
> > > On 2016/08/17 09:09:39, Mounir Lamouri wrote:
> > > > Usually, we mark the status as "stable" for a release or two before
> removing
> > > the
> > > > flag entirely. Is there a reason I'm missing why you prefer to drop the
> > flag?
> > > 
> > > No reason, I just have no prior experience with moving features to stable
> and
> > > based on the comment at line 17 above, which says '... stable features
> should
> > be
> > > rare ...' I've thought it would be better to remove the flag entirely,
since
> > > there are few places that need to be updated (I believe I got every single
> > place
> > > that need to be updated in this CL) and so it would be easy to remove. I
can
> > > mark the feature as 'stable' for now if that's the preferred way.
> > 
> > +1 to marking stable rather than ripping all the gates out.
> > Note that I'm investigating an MSE audio/videoTrack-related w3c test suite
> > failure at the moment (it looks like we need to fire 'change' at
> > {audio,video}Tracks when selected/enabled track changes. Or maybe the new
test
> > suite test is doing something wrong. I'll fix one or both of Chromium and
w3c
> > test suite shortly. Late changes like what I'll probably need to do further
> > justify marking 'stable' instead of ripping out the gates.
> 
> Note: The failing w3c tests are within
> https://github.com/w3c/web-platform-tests/pull/3182.

Ok, I've updated the CL to just flip the switch in RuntimeEnabledFeatures.in

[commit-bot: I haz the power, 2016-08-18 03:46:00]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-18 03:46:01]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[servolk, 2016-08-18 05:51:26]

The CQ bit was checked by servolk@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-18 05:51:40]

Dry run: 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-08-18 05:52:48]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-18 05:52:49]

Dry run: Try jobs failed on following builders:
  ios-device on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...)

[mlamouri (slow - plz ping), 2016-08-18 13:30:08]

lgtm

Can you link to the Intent to Ship email?

[servolk, 2016-08-18 17:05:35]

Description was changed from

==========
Mark HTMLMediaElement media tracks functionality as stable

This will make HTMLMediaElement media tracks accessible and usable
by default, without enable-experimental-web-platform-features flag.

BUG=249427,249428
==========

to

==========
Mark HTMLMediaElement media tracks functionality as stable

This will make HTMLMediaElement media tracks accessible and usable
by default, without enable-experimental-web-platform-features flag.
Intent to ship notification:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/Yk8u329AmIs

BUG=249427,249428
==========

[servolk, 2016-08-18 17:05:44]

On 2016/08/18 13:30:08, Mounir Lamouri wrote:
> lgtm
> 
> Can you link to the Intent to Ship email?

Done.

[servolk, 2016-08-18 17:05:54]

The CQ bit was checked by servolk@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-18 17:06:25]

Dry run: 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-08-18 20:49:09]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-18 20:49:10]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[servolk, 2016-08-18 20:54:59]

The CQ bit was checked by servolk@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-18 20:55:29]

Dry run: 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-08-18 22:22:06]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-18 22:22:07]

Dry run: This issue passed the CQ dry run.

[wolenetz, 2016-08-19 20:12:00]

lgtm % approvals on the intent to ship from API owners.
Note that https://bugs.chromium.org/p/chromium/issues/detail?id=639151 shows
that some of the tracks functionality required for MSE is still missing.