webrtcHacks
Chrome will be identified as Safari if webkitGetUserMedia is removed
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.
What about using something unique instead of a related WebRTC Api like getUserMedia?
Like window.chrome ?
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!
@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?
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.
@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..
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 :-(
haha, ok, closing my PR, since it looks like this won't be moving forward this way ¯_(ツ)_/¯
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?
Someone mentioned window.chrome exists in Edge too
On Wed, Apr 11, 2018, 14:57 Philipp Hancke [email protected] 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 .
@zaxy78 good point, it does. However we can tell Edge apart since it has RTCIceGatherer from ORTC
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 :)
https://bugs.chromium.org/p/chromium/issues/detail?id=946516 -- this breaks on http because Chrome 74 removed webkitGetUserMedia there.
https://web.dev/migrate-to-ua-ch/ might solve the problem. We just need the major version anyway.
@beaufortfrancois can you find folks with an opinion on the approach in https://github.com/webrtcHacks/adapter/pull/1103 ?
I don't have a ton of context (e.g. why do we need to detect Chromium here?), but superficially, the approach seems reasonable.
Some WebRTC features are only available in certain versions (and there are bugs so you often need version detection anyway) so there is a ton of application code that looks "what browser am I in and what workaround is required here. Proper feature detection is better but a lot of these things do not have any exposed API surface.
Shouldn't be necessary in 2024 but ... it is. Let me see if I can revive #1103...
