Chrome will be identified as Safari if webkitGetUserMedia is removed

[foolip]

A continuation of https://github.com/webrtc/adapter/issues/712, or a subset thereof. After some changes this is the remaining problematic code:
https://github.com/webrtc/adapter/blob/0a293a9803dcd612cb73c147218a81d56405d6bd/src/js/utils.js#L151

This is probably blocking https://bugs.chromium.org/p/chromium/issues/detail?id=692736, as being identified as Safari might have other consequences.

[KaptenJansson]

What about using something unique instead of a related WebRTC Api like getUserMedia?

Like window.chrome ?

[KaptenJansson]

@fippo @alvestrand

[rtzm]

I've run into this issue as well when trying to use this library for an app that I want to run on mobile. The browser when running on Chrome for iOS is being read as Safari version 604. Can /Chrome/ be read in from the User Agent with something like navigator.userAgent.match(/Chrom(e|ium)\/(\d+)\./))?

Otherwise, this is a really helpful library! thanks a bunch, all!

[fippo]

@rtzm but in that case you want the shim code to be the safari shim even though it is chrome?

@KaptenJansson hrm... how does that behave in chrome on ios?

[rtzm]

I just manually tested window.chrome and window.chrome.webstore on chrome for iOS, and both are undefined, although both should work for Chrome for desktop. Made a PR to add this feature detection here.

It also looks like detecting the correct method for getUserMedia on Chrome for iOS is moot, because iOS 11 doesn't allow Chrome to implement WebRTC: http://www.openradar.me/33571214.

[zaxy78]

@rtzm all browser on iOS are built on top of (WKWebVIew with) Apple's WebKIt engine.
Sadly, all Chrome has is a nice wrapped package for us. that's it. (see Google's past announcement)

So where getUserMedia() works on Safari, it's still blocked on WKWebView..

[fippo]

window.chrome.webstore does not work in Brave unfortunately which supports RTCPeerConnection (and is, no surprise, using the chrome version.
And just checking for window.chrome yields true in Edge :-(

[rtzm]

haha, ok, closing my PR, since it looks like this won't be moving forward this way ¯_(ツ)_/¯

[fippo]

wondering if just window.chrome is a good way to identify chrome. This would cover chrome, opera and brave at least.

@foolip do you know if there is any description of window.chrome?

[zaxy78]

Someone mentioned window.chrome exists in Edge too

…

On Wed, Apr 11, 2018, 14:57 Philipp Hancke ***@***.***> wrote: wondering if *just* window.chrome is a good way to identify chrome. This would cover chrome, opera and brave at least. @foolip <https://github.com/foolip> do you know if there is any description of window.chrome? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://github.com/webrtc/adapter/issues/764#issuecomment-380426029>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACRSrziZtI8yWTnzR_QuefzUTBeFSbk2ks5tne-NgaJpZM4RzyuY> .

[fippo]

@zaxy78 good point, it does. However we can tell Edge apart since it has RTCIceGatherer from ORTC

[foolip]

I know there are Chromium-based browsers which don't have window.chrome, and some that do, so I'd say that's worse that UA sniffing :)

[fippo]

https://bugs.chromium.org/p/chromium/issues/detail?id=946516
-- this breaks on http because Chrome 74 removed webkitGetUserMedia there.