The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7acdd748b1ef6a8a2d957c9f8a14e6873f537d25

commit 7acdd748b1ef6a8a2d957c9f8a14e6873f537d25
Author: Adam Parker <amp@chromium.org>
Date: Mon Jun 26 20:45:18 2017

[VrShell] Temporarily disable Media Router dialog when in VR.

This will be re-enabled when the dialog can be displayed properly in binocular vr.

Bug:  733410 
Change-Id: Ia40339a0538b8c4631c21e6e6e9d87fbaa67dc5a
Reviewed-on: https://chromium-review.googlesource.com/547076
Commit-Queue: Adam Parker <amp@chromium.org>
Reviewed-by: Jennifer Apacible <apacible@chromium.org>
Cr-Commit-Position: refs/heads/master@{#482387}
[modify] https://crrev.com/7acdd748b1ef6a8a2d957c9f8a14e6873f537d25/chrome/browser/media/router/media_router_dialog_controller.cc

I was finally able to see a Cast icon using a dev build (using the html5 test video page from quirkmodes.org).

Unfortunately the above change does not resolve the issue (I still get a dialog popping up).  I believe the issue is that I set the check to not create the dialog controller if we are in vr, but at the point the controller is getting created we aren't in vr so it does get created.

I have another change I'm working on now that instead suppresses the creation of the actual dialog instead of the controller.

Since the CL didn't solve the problem, we should revert the changes.

Ack, I'll revert it.

Something similar is probably needed to solve part of the problem (there are apparently two different paths and only one of them works on dev builds normally), but it's preferred in a different location.  See Anton's comments in the change referenced below.

The follow up change https://chromium-review.googlesource.com/c/549516/ should make sure everything is properly disabled.

Can you explain in more detail why you want to disable just the dialog, versus disabling the Presentation API and Android Remote Playback backends entirely?

There are significant differences in the Web platform and user interaction.  When you just disable the dialog, the page will still be able to observe screen availability and will show a Cast button.  With the CL in progress, it will appear that the user is requesting and cancelling presentation, which will give the site a false signal and will pollute their (and our) metrics.  It's also a pretty bad user experience for the site to offer Cast button that is non-functional.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f696a253a11a6d331b5a490110300f6c0acd93ae

commit f696a253a11a6d331b5a490110300f6c0acd93ae
Author: Adam Parker <amp@chromium.org>
Date: Tue Jun 27 17:33:41 2017

Revert "[VrShell] Temporarily disable Media Router dialog when in VR."

This reverts commit 7acdd748b1ef6a8a2d957c9f8a14e6873f537d25.

Reason for revert: Doesn't disable the dialog (and isn't the correct place to do so).

Original change's description:
> [VrShell] Temporarily disable Media Router dialog when in VR.
> 
> This will be re-enabled when the dialog can be displayed properly in binocular vr.
> 
> Bug:  733410 
> Change-Id: Ia40339a0538b8c4631c21e6e6e9d87fbaa67dc5a
> Reviewed-on: https://chromium-review.googlesource.com/547076
> Commit-Queue: Adam Parker <amp@chromium.org>
> Reviewed-by: Jennifer Apacible <apacible@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#482387}

TBR=cjgrant@chromium.org,asimjour@chromium.org,apacible@chromium.org,amp@chromium.org

Change-Id: I4a2614b6c6859dd1163b9dff65d76de95d33c234
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug:  733410 
Reviewed-on: https://chromium-review.googlesource.com/550575
Reviewed-by: Amirhossein Simjour <asimjour@chromium.org>
Commit-Queue: Adam Parker <amp@chromium.org>
Cr-Commit-Position: refs/heads/master@{#482666}
[modify] https://crrev.com/f696a253a11a6d331b5a490110300f6c0acd93ae/chrome/browser/media/router/media_router_dialog_controller.cc

As with similar UI, the dialog causes a very bad experience with UI spread across both eyes instead of displayed in both. The user is unable to cancel the dialog without removing the phone from the headset. Thus, the most important thing is to prevent this from happening.

Since the page is not reloaded when putting the phone in the headset, we cannot change the APIs that are exposed to the page. We also can't force the page to re-query for displays.

Looking at the sample code at https://googlechrome.github.io/samples/presentation-api/, it appears the best thing we could do for apps would be to have getAvailability() resolve with false when in VR and fire onchange when entering/exiting VR. Assuming applications are monitoring onchange, they would update their UI appropriately.

I'm not sure how much work it would be to implement this, but if it's non-trivial, it's probably not worth it. Initial VR usage will be very small compared to the overall user base, and users are unlikely to try to cast from within a VR headset. One thing we might be able to do with less effort is to disable the icon in the default controls when in VR. Default controls are used much more often on mobile, so this should address many sites.

If you can do onvron/onvroff logic per media element in Blink, you should be able to add controlsList="noremoteplayback" or disableRemotePlayback (if you want to disable the whole thing vs just the native controls button) to the element when entering VR and restoring the previous value when leaving.

Otherwise, the logic will be a bit more complicated. We support RuntimeFeatures::RemotePlaybackBackendEnabled, for example, but don't assume it will change in runtime. I'm not sure if there's a good way to disable Presentation API on desktop that can be reused on Android.

I don't think my concerns should block the patch in progress (esp. given the potential impact is low), but I want to understand how we can get to reasonable and predictable API behavior in VR mode.  

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0a86014fc87636ee1e907da7d98117fd9db645f0

commit 0a86014fc87636ee1e907da7d98117fd9db645f0
Author: Adam Parker <amp@chromium.org>
Date: Tue Jun 27 23:38:44 2017

[VrShell] Disable Media Router dialog when in VR.

This only disables the dialog (the icon still shows up) and will record
a 'cancel dialog' action if the user does actually click on the icon in
VR.  However, this is a temporary mitigation until the dialog can be
properly displayed in VR and there are likely few users who will 1. be
both a VR and Cast user and 2. click on the icon while in VR.

Bug:  733410 
Change-Id: Ie1d891e98dc6c988968d4118291508c053df18d9
Reviewed-on: https://chromium-review.googlesource.com/549516
Reviewed-by: Jennifer Apacible <apacible@chromium.org>
Reviewed-by: Anton Vayvod <avayvod@chromium.org>
Commit-Queue: Adam Parker <amp@chromium.org>
Cr-Commit-Position: refs/heads/master@{#482794}
[modify] https://crrev.com/0a86014fc87636ee1e907da7d98117fd9db645f0/chrome/android/java/src/org/chromium/chrome/browser/media/remote/RemoteMediaPlayerBridge.java
[modify] https://crrev.com/0a86014fc87636ee1e907da7d98117fd9db645f0/chrome/browser/media/android/router/media_router_dialog_controller_android.cc

Marking as fixed.  Re #13, we have scheduled an in person discussion and will follow up with re-enabling in  issue 736568 .

verified in 61.0.3143.0

Issue 738196 tracks implementing a better solution for disabling displays in VR.