Update WebAuthentication API data for Safari.

[alanwaketan]

Here are the relase notes:
Safari 13: https://developer.apple.com/documentation/safari-release-notes/safari-13-release-notes.
iOS 13.3: https://developer.apple.com/documentation/ios-ipados-release-notes/ios-ipados-13_3-release-notes.

[alanwaketan]

Sorry, I'm new to the repo. Can anyone walk me through the checks? Like, why are they failing?

[sideshowbarker]

Hi @alanwaketan — great to see you here

The failures are for the npm test check — and specifically for the lint part of that, which includes checking for know browser versions.

• https://github.com/mdn/browser-compat-data/pull/6328/checks?check_run_id=805860505#step:5:175
• https://travis-ci.org/github/mdn/browser-compat-data/builds/701885160#L266

The problem is that this repo doesn’t yet know about the 13.3 version of iOS Safari; instead it only knows about versions 13 and 13.4:

browser-compat-data/browsers/safari_ios.json

Lines 147 to 153 in 76d6ede

	"13.4": {
	"release_date": "2020-03-24",
	"release_notes": "https://developer.apple.com/documentation/safari-release-notes/safari-13_1-release_notes",
	"status": "current",
	"engine": "WebKit",
	"engine_version": "609.1.20"
	},

So, to make the repo recognize 13.3 as a known iOS Safari version, there would need to be a separate PR that updates the https://github.com/mdn/browser-compat-data/blob/master/browsers/safari_ios.json file with details for the 13.3 release similar to those shown above for the 13.4 release.

[alanwaketan]

@sideshowbarker Nice to see you in this repo! I will upload another pull request then.

[othermaciej]

Why is Safari 13.1 labeled as Safari 13.4 in here? That seems like another PR-worthy bug (if there is no deep reason). The actually existing 13.x versions are 13.0.1, 13.0.2, 13.0.3, 13.0.4, 13.0.5, 13.1, 13.1.1

[alanwaketan]

Why is Safari 13.1 labeled as Safari 13.4 in here? That seems like another PR-worthy bug (if there is no deep reason). The actually existing 13.x versions are 13.0.1, 13.0.2, 13.0.3, 13.0.4, 13.0.5, 13.1, 13.1.1

I will try to correct all these faults in my next PR, and will post it to our webkit channel to let folks do proof reading.

[sideshowbarker]

Heya @othermaciej. This repo maintains browser-version data both for macOS Safari and, separately, for iOS Safari. So the error the linter is reporting here is "13.3" is NOT a valid version number for safari_ios (not for macOS).

The version data for both macOS Safari and iOS Safari here has so far been maintained by non-Apple volunteer contributors, so it’s somewhat unsurprising that it may not be as accurate as it should be. If somebody from the WebKit project would be willing to take some time to review it and correct/update it where necessary, that would be super great.

[Elchi3]

Maintainer here. I was about to write what @sideshowbarker said :) Let me know if I can help to sort this out in any way and welcome to mdn-browser-compat-data 🎉

[sideshowbarker]

https://github.com/mdn/browser-compat-data/blame/master/browsers/safari_ios.json is the relevant version-data file.

[alanwaketan]

Just out of curiosity, what's the benefit to have the engine version in the db?

[sideshowbarker]

Just out of curiosity, what's the benefit to have the engine version in the db?

When somebody is adding new data, tt allows the related tooling to catch (1) typos, (2) version-formatting inconsistencies, and (3) copypasta wrong-version numbers.

What I mean by version-formatting inconsistencies is that it ensures there’s not one contributor adding data with a 13.0 version number while another contributor is adding it with 13. We always use one or the other.

As far copypasta wrong-version numbers, what I mean is, for example: when adding data for a new feature recently, I accidentally pasted a safari_ios version number (13.4, I think) into the value of the samsunginternet_android key — because they’re right next to each other in the JSON source, so it’s an easy mistake to make.

And since samsunginternet_android doesn’t yet have a version 13.4 yet, the tooling caught that and let me know.

So overall it’s a linting thing, and a consistency thing.

[alanwaketan]

@sideshowbarker Thanks for your throughout answer. My question probably lacks too many details to have someone understand it correctly. Specifically, I was trying to ask what the engine_version here is used for?

"13.4": { "release_date": "2020-03-24", "release_notes": "https://developer.apple.com/documentation/safari-release-notes/safari-13_1-release_notes", "status": "current", "engine": "WebKit", "engine_version": "609.1.20" },

[sideshowbarker]

Specifically, I was trying to ask what the engine_version here is used for?

We sometimes use the engine version when trying to figure out which release a particular feature landed in.

As I alluded to earlier, because this project hasn’t yet really had anybody from the WebKit team directly contributing to this repo and doing reviews in the same way that there are people from the Chrome and Firefox teams doing those things, we often have to do a lot of research ourselves to try to identify which Safari release a particular feature ended up shipping in.

So what we sometimes do is, we look in WebKit Trac to find the revision where the feature landed, then based on that, we look at what tag that first went into, and then find the Safari release with the closest engine_version number to that tag.

For example, see #6157 and #6151 (just two examples among many).

https://developer.mozilla.org/en-US/docs/MDN/Contribute/Processes/Matching_features_to_browser_version#Safari has some related details.

[alanwaketan]

Specifically, I was trying to ask what the engine_version here is used for?

We sometimes use the engine version when trying to figure out which release a particular feature landed in.

As I alluded to earlier, because this project hasn’t yet really had anybody from the WebKit team directly contributing to this repo and doing reviews in the same way that there are people from the Chrome and Firefox teams doing those things, we often have to do a lot of research ourselves to try to identify which Safari release a particular feature ended up shipping in.

So what we sometimes do is, we look in WebKit Trac to find the revision where the feature landed, then based on that, we look at what tag that first went into, and then find the Safari release with the closest engine_version number to that tag.

For example, see #6157 and #6151 (just two examples among many).

https://developer.mozilla.org/en-US/docs/MDN/Contribute/Processes/Matching_features_to_browser_version#Safari has some related details.

Now, you have me. Understood. I was confused when I was trying to edit this list because we don't have that internally. And the WebKit version is forever locked to "605.1.15" in our user agent string to prevent finger printing. I will keep the field there in case people outside of WebKit wish to continue updating the data.

[alanwaketan]

The PR to add an entry for iOS 13.3 is here. #6336

[sideshowbarker]

Thanks much!

[alanwaketan]

Thanks, Michael!

[othermaciej]

Heya @othermaciej. This repo maintains browser-version data both for macOS Safari and, separately, for iOS Safari. So the error the linter is reporting here is "13.3" is NOT a valid version number for safari_ios (not for macOS).

iOS Safari uses the same version numbers as Mac Safari. 13.3 and 13.4 are both valid iOS versions, but are not Safari versions. For example, the User-Agent header for iOS Safari on iOS 13.4.1 is Mozilla/5.0 (iPhone; CPU iPhone OS 13_4_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1 Mobile/15E148 Safari/604.1. Notice the Version/13.1, that is the Safari version.

If MDN is choosing to identify iOS Safari by the OS version number instead of the browser version number, then I guess this is consistent, but it's not at all clear from the tables that this one case is an OS version number, while all other browsers, including Chrome for Android, are reported by browser version number instead.

This practice has the potential to confuse, because iOS 13.1 does not come with Safari 13.1, so 13.1 can mean two very different things.

Fixing this is probably beyond the scope of this PR. So sorry for the drive-by comment, but I think this is a real issue that should be fixed.

The version data for both macOS Safari and iOS Safari here has so far been maintained by non-Apple volunteer contributors, so it’s somewhat unsurprising that it may not be as accurate as it should be. If somebody from the WebKit project would be willing to take some time to review it and correct/update it where necessary, that would be super great.

Noted! This is not a complaint, just something I happened to notice that looked wrong.

[othermaciej]

Filed the thing I noticed as #6338

[sideshowbarker]

Filed the thing I noticed as #6338

Thanks much for raising that

If MDN is choosing to identify iOS Safari by the OS version number instead of the browser version number, then I guess this is consistent

Yeah, as #6338 (comment) indicates, that’s in fact the policy that has been in place — and that explains why there was previously no 13.3 version in the https://github.com/mdn/browser-compat-data/blob/master/browsers/safari_ios.json file.

But I had actually forgotten that was the policy in place. So I’m glad you took time to comment here and raise #6338, and I look forward to it getting resolved — because (for the reasons you’ve pointed), the current state of things seems to have a lot of potential to confuse.