Move WebVR feature out of experimental (to off-by-default).

Move WebVR feature out of experimental (to off-by-default).

Otherwise, whenever experimental web platform features are on, VRController
will boot up and try to connect to device::VRService, which simply doesn't
exist unless --enable-webvr is set.

Since --enable-webvr enables the corresponding runtime-enabled feature
already, this shouldn't break WebVR in any case where it previously worked.

However, it does prevent users that enable experimental features (notably,
layout tests) from having spurious messages about VRService failing to connect.

Committed: https://crrev.com/bfed0eec404d787aaf02ad27d23382fb945b19cd
Cr-Commit-Position: refs/heads/master@{#399120}

[jbroman, 2016-06-09 20:24:46]

jbroman@chromium.org changed reviewers:
+ bajones@chromium.org

[jbroman, 2016-06-09 20:24:47]

For me, this removes these spurious messages I was seeing in content_shell and
layout test output:

[20651:20651:0609/161942:ERROR:service_registry_impl.cc(98)] device::VRService
not found

I don't think it will break anything (for reasons given in the CL description),
but let me know if I've missed some reason that this feature must have
status=experimental.

[jbroman, 2016-06-09 20:24:58]

Description was changed from

==========
Move WebVR feature out of experimental.

Otherwise, whenever experimental web platform features are on, VRController
will boot up and try to connect to device::VRService, which simply doesn't
exist unless --enable-webvr is set.

Since --enable-webvr enables the corresponding runtime-enabled feature
already, this shouldn't break WebVR in any case where it previously worked.

However, it does prevent users that enable experimental features (notably,
layout tests) from having spurious messages about VRService failing to connect.
==========

to

==========
Move WebVR feature out of experimental (to off-by-default).

Otherwise, whenever experimental web platform features are on, VRController
will boot up and try to connect to device::VRService, which simply doesn't
exist unless --enable-webvr is set.

Since --enable-webvr enables the corresponding runtime-enabled feature
already, this shouldn't break WebVR in any case where it previously worked.

However, it does prevent users that enable experimental features (notably,
layout tests) from having spurious messages about VRService failing to connect.
==========

[bajones, 2016-06-09 20:50:11]

On 2016/06/09 20:24:47, jbroman wrote:
> For me, this removes these spurious messages I was seeing in content_shell and
> layout test output:
> 
> [20651:20651:0609/161942:ERROR:service_registry_impl.cc(98)] device::VRService
> not found
> 
> I don't think it will break anything (for reasons given in the CL
description),
> but let me know if I've missed some reason that this feature must have
> status=experimental.

Ah, I once again failed to understand the meaning of the labels in
RuntimeEnabledFeatures.in

Thanks, and LGTM

[jbroman, 2016-06-09 20:54:42]

The CQ bit was checked by jbroman@chromium.org

[commit-bot: I haz the power, 2016-06-09 20:55:13]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2055943002/1

[commit-bot: I haz the power, 2016-06-09 21:37:11]

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

[commit-bot: I haz the power, 2016-06-09 21:37:13]

Try jobs failed on following builders:
  linux_chromium_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[jbroman, 2016-06-09 21:49:44]

The CQ bit was checked by jbroman@chromium.org

[jbroman, 2016-06-09 21:49:45]

Whoops, also needed to update the expectation for global-interface-listing.html,
as this CL unexposes the WebVR API when --enable-webvr is not specified (as is
the case for the default layout test configuration).

[jbroman, 2016-06-09 21:49:45]

The patchset sent to the CQ was uploaded after l-g-t-m from bajones@chromium.org
Link to the patchset: https://codereview.chromium.org/2055943002/#ps20001
(title: "update global-interface-listing-expected.txt")

[commit-bot: I haz the power, 2016-06-09 21:50:25]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2055943002/20001

[commit-bot: I haz the power, 2016-06-10 00:37:21]

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

[commit-bot: I haz the power, 2016-06-10 00:37:22]

Try jobs failed on following builders:
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_TIMED_OUT, no build URL)

[jbroman, 2016-06-10 02:54:45]

The CQ bit was checked by jbroman@chromium.org

[commit-bot: I haz the power, 2016-06-10 02:55:08]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2055943002/20001

[commit-bot: I haz the power, 2016-06-10 06:24:17]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-06-10 06:24:24]

CQ bit was unchecked

[commit-bot: I haz the power, 2016-06-10 06:25:50]

Description was changed from

==========
Move WebVR feature out of experimental (to off-by-default).

Otherwise, whenever experimental web platform features are on, VRController
will boot up and try to connect to device::VRService, which simply doesn't
exist unless --enable-webvr is set.

Since --enable-webvr enables the corresponding runtime-enabled feature
already, this shouldn't break WebVR in any case where it previously worked.

However, it does prevent users that enable experimental features (notably,
layout tests) from having spurious messages about VRService failing to connect.
==========

to

==========
Move WebVR feature out of experimental (to off-by-default).

Otherwise, whenever experimental web platform features are on, VRController
will boot up and try to connect to device::VRService, which simply doesn't
exist unless --enable-webvr is set.

Since --enable-webvr enables the corresponding runtime-enabled feature
already, this shouldn't break WebVR in any case where it previously worked.

However, it does prevent users that enable experimental features (notably,
layout tests) from having spurious messages about VRService failing to connect.

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

[commit-bot: I haz the power, 2016-06-10 06:25:51]

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