That would work for now (removing the extra boolean check) - but what
happens when we do want to show up in Daydream Home?

We should enter ChromeVR I guess. I can also make it work that way (given the VrShell runtime flag is set, otherwise, we just ignore the VR bit in the intent).

hmm, it is tricker than I think. your canary needs to be on webvr page (like Brandon's example) before you fire the intent. if it was on a regular page, it will just go to Daydream home. Anyway, I will work on this next week.

It looks like the Intent sometimes open the page in browser but sometimes open the page in a Custom tab activity. Using this command should be able to reliably reproduce the issue: adb shell am start -a "android.intent.action.VIEW" -d "https://www.android.com/" --ez "android.intent.extra.VR_LAUNCH" true --ez "android.support.customtabs.extra.user_opt_out" true

There are two issues here:
1. android.intent.extra.VR_LAUNCH shouldn't be used to identify a VR intent. A real VR intent should always has a DAYDREAM_CATEGORY category in the intent.
2. If a VR intent passed Intent filter, vrdisplayactiviate event shouldn't be
fired if Chrome is about to open a new page(this is why we see a regular page splitted into stereo rendering view). This issue can be fixed later when we have
a design for incoming VrIntent. see https://bugs.chromium.org/p/chromium/issues/detail?id=670129

To this specific issue, do nothing should be the right solution. The fabricated intent should be filtered. I was wrong about that we should try to enter ChromeVR.

So this is a WontFix then?

My comment in #4 is probably misleading when I say "do nothing". :p
what I really mean is that Chrome should just ignore the VR bit information in the Intent, instead of try to enter VR mode. I have a fix ready for review soon.

Ah, I see; thanks.

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

commit 203f0669b622c6425388c9d6fc7069dbbe451025
Author: bshe <bshe@chromium.org>
Date: Wed Dec 21 22:25:51 2016

Ignore VR_EXTRA boolean in incoming Intent

As explained in  crbug.com/673019  We should just use DAYDREAM category
to detect if an Intent is a DAYDREAM Intent.

BUG= 673019 

Review-Url: https://codereview.chromium.org/2580093003
Cr-Commit-Position: refs/heads/master@{#440242}

[modify] https://crrev.com/203f0669b622c6425388c9d6fc7069dbbe451025/chrome/android/java/src/org/chromium/chrome/browser/ChromeTabbedActivity.java
[modify] https://crrev.com/203f0669b622c6425388c9d6fc7069dbbe451025/chrome/android/java/src/org/chromium/chrome/browser/vr_shell/VrShellDelegate.java

We probably want to merge this into M56 if possible, so malicious apps can't get chrome into a weird state on stable.

yah. Merge to M56 is a growing pain at this point. This one is probably easy to merge. But I want to avoid merge unless it is security or stability related.

To trigger the strange state, the top page must be a webvr page which listen to a vrdisplayactivate event and request present in the event handler while the malicious app send the intent. Since WebVR is original trial only, I think it is relatively safe. And user can recover from the state easily. So M57 sounds reasonable.