May be related to Issue 669265.

Based on the above issue, we may need to check both Google VR Services and Google Play Services.

As this affects WebVR, we should consider doing this soon.

Hopefully we can also be sure that with said updates the user's phone will be compatible. Otherwise we'll end up directing users to install things that they ultimately can't use.

 Issue 670414  has been merged into this issue.

A few ideas about this has been discussed in  Issue 670414 .
We probably need to create native browser UI which could fire PlayStore intent if user chose to upgrade VrCore (and VrCore is compatible with the device).

Temporarily assign it to myself. I can work on it after cardboard crashes are fixed.
At the same time, if anyone in SEA wants to work on it, feel free to grab it.

Actually, UX is needed first.

Josh, do you mind to find someone to work on this UX? We want to get this done in M58. This should help user better understand why WebVr doesn't work as well as helping drive VrCore installation on K, L and M devices. 

For 57, could we get away with doing the detection and firing off an intent to the play store without showing any extra UX?

I'm not sure where the check would happen though, so it might end up that loading a page that uses WebVR could suddenly redirect you to the Play Store, so that might not be feasible.

We need to check version before use GVR apis. Currently, open a webvr page with magic window mode would trigger it. So if we fire intent directly without any extra UI, we would basically redirect user to play store when navigate to a webvr page. And if user decide to not install VrCore for some reason. Hit the back button would send the user to Chrome again which would try to reload the webvr page, which would send user to VrCore installation again (I didn't test it so I might be wrong on this). So I think some form of Chrome UI is needed as well as an option which allow user to precede without install VrCore.
We can probably implemented it similar to PlayService check in Chrome. 

s/precede/proceed

To summarize, I see the following scenarios:

* User's phone is not compatible with Android VR
* User's phone is compatible, but VR Core is out of date
  * User loads site with magic window content
  * User places phone into Daydream View to initiate VRShell.

Does that cover it?

WRT to magic window mode, it is unfortunate that merely loading a site in 2D mode causes an error for the user. Would it be possible to fail silently and fall back to polyfill, if present?

* User's phone is compatible w/ Android VR, but VrCore is out of date
* User loads site with magic window content
* Behind scenes, Clank checks for VrCore version. Finds it's outdated.
* Clank drops back to polyfill and user views content in magic window mode.
* User decides to view content in VR.
  * Taps Enter VR UI button
    * Error message appears
  * [or] Puts phone in Daydream View
    * DON controller pair
    * In-VR error message appears

Pros:

* Cause of error is easier to understand because it is triggered by a user Enter VR action.
* Users are free to surf in 2D mode w/o problems

Cons:

* User who gets error after only placing phone in DD View is annoyed. They wanted to view content in VR so they went through the steps of putting their phone in a DD View and syncing the controller, but were then confronted by an error message that told them to take the phone out all over again.
* Discrepancies between polyfill and WebVR version of content?

WRT to the above, I supposed other potential Con is developer might not be using polyfill, and site experience may fail entirely, without an error message.

Do we need to worry about the case where the user has already put the device into a daydream view?  Won't the DON flow automatically check VrCore versions and provide a way to update them?  This may still require taking the phone out of the view, but I thought it was out of our control.

Re fallback to polyfill, I'm sure this is possible for a site to do, but I don't think we want to be changing things around on the chrome/clank side like that.

I'm not sure how magic window works though, does it require VrCore or is there a subset of code that can run the basic experience without it?

Focusing only on VrCore there are only the following scenarios I think:
1. VrCore doesn't exist or is out of date, but is available for the device -> provide a message with link to play store to install/update.
2. Missing VrCore and it is not supported on this phone -> provide a message saying so
3. VrCore is up to date, proceed as usual with no messaging to user.


Where it gets confusing to me is when do we check VrCore.  Is it on page load, or when they click on a button to start presenting?

It feels messy if we try to do it on page load. I think something like Josh suggests with a fallback to something that doesn't require VrCore would be better (this isn't the same thing as the polyfill, just some basic implementation of Magic Window), but then still show a button for presenting in VR.

Once the user clicks the button then we check VrCore and prompt per my VrCore scenario's.

WDYT?

For now we can probably start by making sure we have the VrCore scenario's covered and then figure out how we are going to handle magic window and other device scenarios in future iterations.

We should do the check before VR related APIs are called by Chrome. And creating a GvrLayout will call native apis. So we should always check before try to create a GvrLayout(directly or indirectly) in Chrome. I think there are the following cases:
1. magic window
2. enter vr_shell though browser UI (assuming we will have one)
3. present
4. put device to headset
5. open Chrome from VR Home
For case 1, magic window is automatically enabled when navigate to a WebVR page, which means we may need to require user action on a page load. This is not great. We have two ways to solve this:
a. use a non intrusive UI to let user know if VrCore installation/upgrade is needed. Non-intrusive means page can still load. But magic window is disabled. And our UI can be in the canvas area that has WebVR content(similar to flash upgrade UI as Micheal suggested) or a UI that popup from bottom which could be easily dismissed by a simply tap on the screen.
b. implement Api that required by magic window in Chrome. I imagine this is a subset of APIs which shouldn't take long to implement. This way, we dont need to access VR APIs to support magic window and loading a page won't ask user to install/upgrade VrCore.
For case 2, we should be able to insert a UI before entering GVR's UI for inserting phone and pair. And this UI can be a modal window.
For case 3, we could either disable presentation button or show a modal window after the presentation button is pressed.
For case 4, IIRC, we current won't re-enter Chrome after DON. The reason is we don't try to register Chrome Intent with VrCore if VrCore is not what Chrome expect. Given that the API which register Intent is a Java api, it should be safe to use even the version doesn't match (jdduke?). We could probably change the behavior to register Chrome intent always. But this would require user update VrCore in VR like josh@ said. I dont know if there is a better solution for this case. Perhaps an API which would let Chrome do some tasks before DON start would help. I think adam@ proposed such API for fullscreen a while ago?
For case 5, we might want to implement a UI in VR which ask user to update VrCore(similar to case 4?). In the short term, we can probably just ask user go back to 2d and update VrCore.

jdduke@ is there any other VR app that currently has a minimal version requirement for VrCore? How do they handle the situation?

For M58, can we just do a upgrade UI similar to chrome's plugin missing/crashed ui here: https://www.google.ca/search?q=chromium+plugin+missing+ui&espv=2&biw=1510&bih=1017&tbm=isch&source=lnms&sa=X&ved=0ahUKEwjR0IeI2fvRAhVH7oMKHYIzCQsQ_AUIBigB&dpr=1#imgrc=pRm8s-xNXIOoZM:
This UI wont block page loading and it is a familar UI that user understood.

I think this could address the magic window case. And this is the only case that we care in M58. For other cases, we may need deeper discussion about when and where to show the upgrade UI. They could happen later.

I'd be a little hesitant to replace the canvas content with an upgrade UI simply because it isn't the canvas content that has run into an issue, it's the VR system (which isn't explicitly linked to any particular page element.)

For that reason, maybe an infobar would suit the needs here better? The code for the "Rats! WebGL hit a snag." bar is here: https://cs.chromium.org/chromium/src/chrome/browser/gpu/three_d_api_observer.cc That wouldn't interrupt page execution at all but is still recognizable as a call to action for the user.

If we wanted to be even MORE subtle about it we could also look into a "popup/plugin blocked" style badge on the omnibar, but that probably (intentionally) has a pretty low clickthrough rate.

+1 to the infobar, this was what I was intending to advocate for, but there was some miscommunication.

If we're thinking about introducing UI here, we'll need to run it by Chrome
UI review.  And probably makes sense for us to loop in Josh & Rebecca now.

Yeah. I already assigned this to josh@ for discussion purpose. +rebecca too

To summarize, I think we will need to two type of UI for this:
1. non intrusive UI for cases like page loading indirectly triggers VR(magic window)
2. UI which gate user from enter VR after a user gesture(put phone into headset , click presentation button or launch from VrHome). This UI might need VR version too.
We would need to implement #1 for M58 at least. 

WIP upgrade prompt infobar attached.

Deleted: vrcore-upgrade-prompt.png 339 KB

	vrcore-upgrade-prompt.png 339 KB View Download

Updated version per feedback from srahim@.

Deleted: vrcore-upgrade-prompt-2.png 338 KB

	vrcore-upgrade-prompt-2.png 338 KB View Download

One more tweak, removing the dismiss button, since the "X" already does the same thing.

Deleted: vrcore-upgrade-prompt-3.png 335 KB

	vrcore-upgrade-prompt-3.png 335 KB View Download

Adam, note that there's a new image asset required for this bug, in the form of the VR goggles. I need to confirm with Chrome UX that it's appropriate to use a new icon in that position. I'm not certain whether only notification icons are allowed to go in that spot. And if so, whether WebVR is technically a permission.

We may also want to include "install" in the string, since it is possible that user haven't install VR service on their phone yet. Also, uma stats about how often the dialog showed and how likely user click the button would be nice.
assign to Adam since he expressed interest in working on this.

We should distinguish between "not installed" and "need to update" and create distinct infobars for each.

What do users on older Android devices see? Hopefully we aren't going to tell them to install software that doesn't run on their phone?

Good question, we need a flexible way to check if Vr Service is supported on current platform or not. If it is not supported, we should not show any popups. 
I suspect that the minimal required platform version could be different between Chrome and GVR over time. We may need GVR api support to properly detect this.

Re comment #30, I'll look into the technical parts of the info bar implementation, it may not be possible to override the icon without some changes.

Re comment #33 for install we can just change the text pretty easily, but if we want a different flow that will be harder.  I'm also not sure what GVR api implies, doesn't GVR api come from VrCore?  If so, how can we use it if it hasn't been installed (or can't be installed)?

I am referring to the API that the static lib/common.aar provides. But we can also implement our own logic in Chrome too. Ideally, we want to pull the information from a server or somewhere so that we dont need to upgrade Chrome to bump the minimal required version. But it might be overkill at this moment. We can probably just hardcode K+ for now, WDYT?

We could use something similar to the finch study variation params that we use for cardboard support check, but we should probably sync with the finch team to see if that is a supported use case.

hardcoding to K+ for now sounds fine.

So anything before K won't see a prompt and if they go to a WebVR site they will get a message about no devices being available.  Is updating that message part of this issue or should we file a separate one for it?

Hi Adam,

Can you assign this bug to Vitali once it is done for testing? So Vitali can easily track the testing request.

Will do.  I'm still working through some scenario's on old devices which weren't working with my initial patch.  I should be updating the change soon with a version that works for all of them.

Got sidetracked by  issue 693298  while trying to figure why it wasn't working sometimes.

I'll make one more attempt to verify it on an older device (which shouldn't be able to get an old version of Vr services and so not hit  issue 693298 , but if that still doesn't work I will opt for submitting the current patch as is with only the update flow working to get the strings in before feature freeze.

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

commit c4911c48c072e710d9948a470936030ccb105945
Author: amp <amp@chromium.org>
Date: Fri Feb 17 20:39:17 2017

Show an infobar when VR services need to be installed or updated.

BUG= 670166 

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

[add] https://crrev.com/c4911c48c072e710d9948a470936030ccb105945/chrome/android/java/res/drawable-hdpi/vr_services.png
[add] https://crrev.com/c4911c48c072e710d9948a470936030ccb105945/chrome/android/java/res/drawable-mdpi/vr_services.png
[add] https://crrev.com/c4911c48c072e710d9948a470936030ccb105945/chrome/android/java/res/drawable-xhdpi/vr_services.png
[add] https://crrev.com/c4911c48c072e710d9948a470936030ccb105945/chrome/android/java/res/drawable-xxhdpi/vr_services.png
[add] https://crrev.com/c4911c48c072e710d9948a470936030ccb105945/chrome/android/java/res/drawable-xxxhdpi/vr_services.png
[modify] https://crrev.com/c4911c48c072e710d9948a470936030ccb105945/chrome/android/java/src/org/chromium/chrome/browser/vr_shell/VrShellDelegate.java
[modify] https://crrev.com/c4911c48c072e710d9948a470936030ccb105945/chrome/android/java/strings/android_chrome_strings.grd
[modify] https://crrev.com/c4911c48c072e710d9948a470936030ccb105945/components/infobars/core/infobar_delegate.h
[modify] https://crrev.com/c4911c48c072e710d9948a470936030ccb105945/tools/metrics/histograms/histograms.xml

Some updates.  https://codereview.chromium.org/2699643003 landed which should show the prompt when VrCore is out of date and the user tries 'present'.  This gets the needed strings in by string freeze, but future adjustments are still needed before branch point.

Due to  issue 693298  if VrCore is too far out of date or not installed then WebVR API calls will not be able to detect any devices and therefor not show any prompt to the user.

I am working on a fix for this, but a complete solution (instead of just a hack) may take a bit longer.

Also, I apparently put the wrong version on the change and used the arm64 version of 160723800 instead of the arm version of 160723799.  This means that KLM devices (which don't actually have access to VrCore through the play store yet) would potentially still see the prompt even if they were using the latest version available.

I'm working on changing my version check over to bshe@'s native check so this shouldn't be an issue.  Hopefully I can have that in place before the next dev release goes out.

Lastly, pre-K devices will not be shown any prompt, but if there is a KLM device that isn't supported by VrCore they will be directed to the Play Store page but then see a message about their device not being supported.  That doesn't seem like the worst scenario, but just FYI that's the current behavior.

Screenshots of the current info bar.

Install: https://screenshot.googleplex.com/zYxyqivpepk
Update: https://screenshot.googleplex.com/QdPCdt9DuZp

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

commit 95ffecbdb167104df9c8c8f86e1826cb17122078
Author: amp <amp@chromium.org>
Date: Thu Feb 23 15:56:27 2017

Use VrCoreCompatibility check for whether to show an infobar instead of Android package manager.

BUG= 670166 

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

[modify] https://crrev.com/95ffecbdb167104df9c8c8f86e1826cb17122078/chrome/android/java/src/org/chromium/chrome/browser/vr_shell/VrCoreVersionChecker.java
[modify] https://crrev.com/95ffecbdb167104df9c8c8f86e1826cb17122078/chrome/android/java/src/org/chromium/chrome/browser/vr_shell/VrCoreVersionCheckerImpl.java
[modify] https://crrev.com/95ffecbdb167104df9c8c8f86e1826cb17122078/chrome/android/java/src/org/chromium/chrome/browser/vr_shell/VrShellDelegate.java

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

commit 24b50378a13f0099e231bcbfefaea67eec005ab3
Author: amp <amp@chromium.org>
Date: Fri Mar 03 02:53:14 2017

Intercept WebVR api calls and check for VrCore compatibility.

Proof of concept only, not ready for submitting.

BUG= 670166 

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

[modify] https://crrev.com/24b50378a13f0099e231bcbfefaea67eec005ab3/chrome/android/java/src/org/chromium/chrome/browser/vr_shell/VrCoreVersionChecker.java
[modify] https://crrev.com/24b50378a13f0099e231bcbfefaea67eec005ab3/chrome/android/java/src/org/chromium/chrome/browser/vr_shell/VrCoreVersionCheckerImpl.java
[modify] https://crrev.com/24b50378a13f0099e231bcbfefaea67eec005ab3/chrome/android/java/src/org/chromium/chrome/browser/vr_shell/VrShellDelegate.java

This bug requires manual review: There is .grd file changes and we are only 52 days from stable.
Please contact the milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), bhthompson@(cros), govind@(desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Re: merge review.  Note that the grd changes are already in 58 and it's only the last change https://crrev.com/24b50378a13f0099e231bcbfefaea67eec005ab3 that didn't make it in.

@Vitali, this landed in Canary version 59.0.3032.0 if you want to start testing it out.

Still waiting for the merge approval for 58.

Merge approved for M58 branch 3029.

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

commit 19417faca2532a7db0082040e47fbea53cea5c48
Author: bshe <bshe@chromium.org>
Date: Mon Mar 06 23:50:42 2017

Intercept WebVR api calls and check for VrCore compatibility.

Proof of concept only, not ready for submitting.

BUG= 670166 

Review-Url: https://codereview.chromium.org/2701523008
Cr-Commit-Position: refs/heads/master@{#454482}
(cherry picked from commit 24b50378a13f0099e231bcbfefaea67eec005ab3)

Review-Url: https://codereview.chromium.org/2728393003 .
Cr-Commit-Position: refs/branch-heads/3029@{#33}
Cr-Branched-From: 939b32ee5ba05c396eef3fd992822fcca9a2e262-refs/heads/master@{#454471}

[modify] https://crrev.com/19417faca2532a7db0082040e47fbea53cea5c48/chrome/android/java/src/org/chromium/chrome/browser/vr_shell/VrCoreVersionChecker.java
[modify] https://crrev.com/19417faca2532a7db0082040e47fbea53cea5c48/chrome/android/java/src/org/chromium/chrome/browser/vr_shell/VrCoreVersionCheckerImpl.java
[modify] https://crrev.com/19417faca2532a7db0082040e47fbea53cea5c48/chrome/android/java/src/org/chromium/chrome/browser/vr_shell/VrShellDelegate.java

This should now be on 58 with any version greater than 58.0.3029.6 (it's been merged to the branch but I haven't seen an official release yet).

Assigning to Vitali to verify.

Quick status. Current VrCore version is 1.3

1. On Pixel devices with Android N:
 - Update prompt appears only if VrCore 1.0 is installed (which comes by default with Android N)
 - Update prompt is absent if installed VrCore version is 1.1 or 1.2

2. On "K L M" devices VrCore is absent by default. Install prompt appears, it leads to the Play Store page. But it's still not possible to install VrCore from Play Store, it says "Device isn't compatible with this version".

please find detailed results here:  https://docs.google.com/spreadsheets/d/1gpsNM7YY9mqV_N4A_un5a13gttfKn1upWZ59lkFmS5E/edit#gid=1371012643