Ios_chr ua detection is not correct

[chenyulun]

A bug report

What

CriOS/92.0.4515.90Supported features promise.any ios_saf/11.0.0 Does not support feature promise.any

Details

1. device： iPhone 7P
2. OS: IOS 14.8
3. chrome： 92.0.4515.90

const polyfillLibrary = require('polyfill-library');
// ios_chr
const ua = 'Mozilla/5.0 (iPhone; CPU iPhone OS 14_8 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/92.0.4515.90 Mobile/15E148 Safari/604.1';
// 手机 ios_saf
// const ua = 'Mozilla/5.0 (iPhone; CPU iPhone OS 14_8_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.1.2 Mobile/15E148 Safari/604.1';
console.log(polyfillLibrary.normalizeUserAgent(ua))
 // ios_chr : ios_saf/11.0.0
//  ios_saf : ios_saf/14.1.0

Ios Safari and WebKit kernel information

https://raw.githubusercontent.com/mdn/browser-compat-data/main/browsers/safari_ios.json

Judging UA by ios Safari and ios Chrome by 'Safari/604.1' is inaccurate The actual UA displayed does not match the engine_version of the version release list

by the way: macos safari ua: "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.1 Safari/605.1.15"

{
  "14.1": {
  "release_date": "2021-04-26",
  "release_notes": "https://developer.apple.com/documentation/safari-release-notes/safari-14_1-release-notes",
  "status": "retired",
  "engine": "WebKit",
  "engine_version": "611.1.21"
}
}

CriOS/ X.X.X is removed from iOS_CHR, and the webKit version is converted to iOS_SAF, which will add many polyfills，Is that unreasonable?

[romainmenke]

problem confirmed

At the root this is the same issue as we've seen with Safari since after v11. The information in the user agent string was reduced with parts of it being frozen.

Updating it for Safari itself was (relatively) easy as Safari does still send the relevant information :

const ua = 'Mozilla/5.0 (iPhone; CPU iPhone OS 14_8_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.1.2 Mobile/15E148 Safari/604.1';

For Chrome on iOS the useful information is missing.

To fixed this we need :

• a mapping between CriOS/x.y.z and Safari versioning
• this mapping should be maintainable (how much effort is required to add a version and propagate this information)
• update the user agent parser
• update the user agent normaliser
• update this library
• update and deploy the service

[romainmenke]

After more thought I am unsure if we can fix this at all. Even if we add a mapping for Chrome on iOS we would still have the same issue for every other browser and webview on iOS.

I think it's worth checking CH-UA for these issues and I have asked for some clarification on part of that specification : https://github.com/WICG/client-hints-infrastructure/issues/124

[romainmenke]

Filed bugs with firefox and chromium to see what the response will be :

chromium bug : https://bugs.chromium.org/p/chromium/issues/detail?id=1348792 firefox bug : https://github.com/mozilla-mobile/firefox-ios/issues/11464

[zloirock]

@romainmenke it could be interesting for you https://github.com/WICG/ua-client-hints/issues/229

[romainmenke]

@zloirock thank you :)

I really don't understand how/why it is so hard to expose reliable and precise engine information.

[romainmenke]

This is more complicated than I expected :)

The polyfill library and service uses the Safari browser version on iOS. MDN however switched to the iOS operating system version at the request of Apple : https://github.com/mdn/browser-compat-data/issues/2006#issuecomment-457277312

So we have a mismatch between the data we copy over from MDN and how it will be used in the library and service.

Even if browsers update their user agent strings to include Version/x.y.z we will still have an issue because this contains the browser version.

To fix this we need to update the user agent parser and normaliser. I do not currently have the capacity to take this on.