-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix regex checking for cardboard support #358
Conversation
What's the case here this misses? As it is right now I think |
@gfodor I believe it has to do with the fact that "Cardboard" is the first word that shows up in the navigator.getVRDisplays() name ("Cardboard VRDisplay") on iOS. So
vs on Android:
|
Ah I understand -- I believe I intended these to be |
I'll try that. @brianpeiris and I also just discovered this same bug is preventing us from launching cardboard on firefox android. |
|
i guess its not the end of the world if we just match the substring. sgtm. |
i'd just drop the |
feel free to do btw, so likely you will want to check |
src/utils/vr-caps-detect.js
Outdated
@@ -70,12 +70,12 @@ export async function getAvailableVREntryTypes() { | |||
? VR_DEVICE_AVAILABILITY.yes | |||
: VR_DEVICE_AVAILABILITY.no; | |||
|
|||
cardboard = displays.find(d => d.capabilities.canPresent && d.displayName.match(/\Wcardboard\W/i)) | |||
cardboard = displays.find(d => d.capabilities.canPresent && d.displayName.match(/\W*cardboard\W*/i)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
when the WebVR Polyfill is used, you can check d.isPolyfilled
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm guessing we need to re-write this all imminently once WebXR lands in origin trial in chrome, so probably not worth worrying about for now
src/utils/vr-caps-detect.js
Outdated
@@ -43,6 +43,8 @@ export async function getAvailableVREntryTypes() { | |||
const isSamsungBrowser = browser.name === "chrome" && navigator.userAgent.match(/SamsungBrowser/); | |||
const isOculusBrowser = navigator.userAgent.match(/Oculus/); | |||
const isDaydreamCapableBrowser = !!(isWebVRCapableBrowser && browser.name === "chrome" && !isSamsungBrowser); | |||
const isIPhone = navigator.userAgent.match(/iPhone/); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would we want to guard against other iDevices? See this regex @robertlong constructed previously: https://github.com/mozilla/hubs/blob/5a8c9635aa1414e5dcabf65d9709b880ce1a6cba/src/utils/ios-audio-context-fix.js#L5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 I don't own an iPad, but I'd assume the bug exists there as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we already have https://www.npmjs.com/package/mobile-detect
in our packages, perhaps that's a good way to check this? or https://www.npmjs.com/package/device-detect
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good work! the WebVR and headset landscape makes this quite tricky to chase down
|
||
// For daydream detection, in a WebVR browser we can increase confidence in daydream compatibility. | ||
const hasDaydreamWebVRDevice = displays.find(d => d.displayName.match(/\Wdaydream\W/i)); | ||
const hasDaydreamWebVRDevice = displays.find(d => d.displayName.match(/daydream/i)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
since you're checking d.capabilities.canPresent
above, do you want to do it here as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is that necessary? I suspect that a daydream display wouldn't show up at all if that were the case.
@@ -70,12 +71,13 @@ export async function getAvailableVREntryTypes() { | |||
? VR_DEVICE_AVAILABILITY.yes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
btw, it can likely be discussed in a separate issue, but should GENERIC_ENTRY_TYPE_DEVICE_BLACKLIST
instead be checking d.capabilities.hasExternalDisplay === false
?
src/utils/vr-caps-detect.js
Outdated
@@ -43,6 +43,8 @@ export async function getAvailableVREntryTypes() { | |||
const isSamsungBrowser = browser.name === "chrome" && navigator.userAgent.match(/SamsungBrowser/); | |||
const isOculusBrowser = navigator.userAgent.match(/Oculus/); | |||
const isDaydreamCapableBrowser = !!(isWebVRCapableBrowser && browser.name === "chrome" && !isSamsungBrowser); | |||
const isIPhone = navigator.userAgent.match(/iPhone/); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 I don't own an iPad, but I'd assume the bug exists there as well?
# Conflicts: # src/utils/vr-caps-detect.js
fix the regex so that ios cardboard is properly detected. Fixes #352
Despite the name of the branch, iOS is explicitly disabled until we fix rendering on carboard iOS. Same for Android/Firefox.