ios_chr data seems wrong
romainmenke opened this issue · 3 comments
When searching in configs for ios_chr
I noticed that these reference both Safari and Chrome versions. This can't be both.
Todo :
- check how these are normalised in the service
- make sure these are consistent and correct
const UA = require('@financial-times/polyfill-useragent-normaliser');
// original
console.log(new UA('Mozilla/5.0 (iPhone; CPU iPhone OS 13_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/103.0.0.0 Mobile/15E148 Safari/604.1'));
UA {
ua: { family: 'ios_saf', major: '11', minor: undefined, patch: '0' },
version: '11.0.0'
}
vs.
const UA = require('@financial-times/polyfill-useragent-normaliser');
// tampered so that `CriOS` comes first
console.log(new UA('Mozilla/5.0 (iPhone) CriOS/103.0.0.0 (KHTML, like Gecko) CriOS/103.0.0.0 Mobile/15E148 Safari/604.1'));
UA {
ua: { family: 'ios_chr', major: '103', minor: '0', patch: '0' },
version: '103.0.0'
}
This seems to be a fallback or legacy but I can't find any examples or tests that results in ios_chr
without manually tampering with a user agent string.
ios_chr
with version: 103
does not match configs where we have safari-like versions for ios_chr
@JakeChampion do you still remember why ios_chr
exists?
It is now legacy and should be removed as we do indeed strip the token from the UA string prior to converting it to a browser+version combination -- https://github.com/Financial-Times/polyfill-useragent-normaliser/blob/2656bd1731ce9c4d5cecba1a5304de0635df4e60/data.json#L59
(It was actually a legacy target back in 2015 but we forgot to tidy up the polyfill configs -- polyfillpolyfill/polyfill-service#416)
Thank you @JakeChampion!
I will do this cleanup in #1204