Change WebView range from ≤37 to ≤4.4?

[queengooborg]

We added WebView Android ≤37 as the first version range to reduce the number of true values lurking around. However, we can also obtain data for WebView Android 4.4 and 4.4.3 by mirroring Chrome Android 30 and 33 respectively. Perhaps we should change the range to be ≤4.4 instead, since we can confirm their data?

[foolip]

IIUC, WebView switched to using Chromium at 4.4, but the versioning scheme was changed later. So 4.4 is the more significant version, where Android WebView switched from WebKit to Chromium. @jpmedley is that right?

[Elchi3]

The story that lead us to invent ≤37 is in this issue, fwiw: #4330

There is also #3561 which advocates "webview_android to refer only to Chromium-based webviews.".

[jpmedley]

Pre 37, WebView was neither Webkit, nor Chromium. It was one built for the Android OS before Google acquired the platform. At least, that's my understanding.

[jpmedley]

The reason for the true and false values was that someone had marked one of those values in MDN's compatibility tables (the source of the origin BCD data). The features were old enough that we had no way to determine which version off Android received them.

[jpmedley]

Sorry for the spam, but I keep remembering different aspects of this. I recall being told that there were different WebViews depending on which Android manufacturer had compiled your OS.

[queengooborg]

Regarding the source of my data, a web article from Google Chrome Developers says that "Since Android 4.4 (KitKat), the WebView component is based on the Chromium open source project... The WebView shipped with Android 4.4 (KitKat) is based on the same code as Chrome for Android version 30... The updated WebView shipped with Android 4.4.3 has the version number 33.0.0.0.

[jpmedley]

Then I don't know why we settled on 37 as the inflection point, unless it had something to do with Android L. 36 shipped with the developer preview. If Chrome 37 has been out by the time L shipped, it probably would have went out with it. Regardless, replacing 4.4 and 4.4.3 with 30 and 33 sounds right.

Would anything earlier become ≤30?

[foolip]

Since it's not been mentioned in this issue yet, here's the engine_version data behind this:

browser-compat-data/browsers/webview_android.json

Lines 75 to 88 in c577e40

	"4.4": {
	"release_date": "2013-12-09",
	"release_notes": "https://chromereleases.googleblog.com/2013/10/chrome-for-android-update.html",
	"status": "retired",
	"engine": "Blink",
	"engine_version": "30"
	},
	"4.4.3": {
	"release_date": "2014-06-02",
	"release_notes": "https://chromereleases.googleblog.com/2014/02/chrome-for-android-update.html",
	"status": "retired",
	"engine": "Blink",
	"engine_version": "33"
	},

That was added in #3877 by none other than @vinyldarkscratch, not sure if there are additional sources listed there which would help.

[ddbeck]

I think a close reading of the page that Vinyl linked to about the relationship between Android and WebView 30, 33, 36, and 37 suggests we should be careful about drawing conclusions about versions before WebView 37:

• We can't safely mirror from Chrome 30 to WebView 30 ("This WebView does not have full feature parity with Chrome for Android")
• The relationship between WebView 33 and Chrome 33 is ambiguous, at best ("The updated WebView shipped with Android 4.4.3 has the version number 33.0.0.0.").
• WebView 36 wasn't a real release, only appearing in a version of Android that was never generally available ("Caution: You cannot publish apps using the L Developer Preview to the Google Play store.").

I'm not convinced that we can safely move the version range from ≤37 to 4.4 or 4.4.3, based on the information we have.

But even if we could, I'm not excited about this proposal. It's not clear to me that it makes contributing data any easier and, as far as I know, there's no consumer or audience that seems especially concerned about the exact boundary here. If we're going to put any more energy into this idea, we ought to have that first.

[jpmedley]

I wonder if this is why we made the decision to use ≤37 and we've simply forgotten. Joe Medley | Technical Writer, Chrome DevRel | [email protected] | 816-678-7195 *If an API's not documented it doesn't exist.*

…

On Thu, Dec 10, 2020 at 4:56 AM Daniel D. Beck ***@***.***> wrote: I think a close reading of the page that Vinyl linked to about the relationship between Android and WebView 30, 33, 36, and 37 <https://developer.chrome.com/docs/multidevice/webview/overview/#what-version-of-chrome-is-it-based-on> suggests we should be careful about drawing conclusions about versions before WebView 37: - We can't safely mirror from Chrome 30 to WebView 30 ("This WebView does not have full feature parity with Chrome for Android") - The relationship between WebView 33 and Chrome 33 is ambiguous, at best ("The updated WebView shipped with Android 4.4.3 has the version number 33.0.0.0."). - WebView 36 wasn't a real release, only appearing in a version of Android that was never generally available ("Caution: You cannot publish apps using the L Developer Preview to the Google Play store."). I'm not convinced that we can safely move the version range from ≤37 to 4.4 or 4.4.3, based on the information we have. But even if we could, I'm not excited about this proposal. It's not clear to me that it makes contributing data any easier and, as far as I know, there's no consumer or audience that seems especially concerned about the exact boundary here. If we're going to put any more energy into this idea, we ought to have that first. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#7543 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6S7C5TD2QITEWG3HZS2X3SUDARXANCNFSM4UGLNOGQ> .

[queengooborg]

It's known that WebView Android explicitly disables certain features. Perhaps that is what the documentation means, regarding WebView for Android 4.4?

On a related note, I recently managed to get my hands on an Android 4.4 emulator as well, so I'll be able to test and submit data with its assistance. That should help with getting some more ranges turned into real values in the future.

[jpmedley]

"It's known that WebView Android explicitly disables certain features. Perhaps that is what the documentation means, regarding WebView for Android 4.4?" I'm not sure what you mean by that. WebView lacks certain features because they're provided by the native app wrapper. Joe Medley | Technical Writer, Chrome DevRel | [email protected] | 816-678-7195 *If an API's not documented it doesn't exist.*

…

On Fri, Dec 11, 2020 at 12:37 PM Queen Vinyl Darkscratch < ***@***.***> wrote: It's known that WebView Android explicitly disables certain features. Perhaps that is what the documentation means, regarding WebView for Android 4.4? On a related note, I recently managed to get my hands on an Android 4.4 emulator as well, so I'll be able to test and submit data with its assistance. That should help with getting some more ranges turned into real values in the future. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#7543 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6S7C3KG3ZR3NZDH4XHTXDSUJ7IVANCNFSM4UGLNOGQ> .

[queengooborg]

"It's known that WebView Android explicitly disables certain features. Perhaps that is what the documentation means, regarding WebView for Android 4.4?" I'm not sure what you mean by that. WebView lacks certain features because they're provided by the native app wrapper.

Sorry, I'm bad at explaining things...

What I mean is: there are several features that are in Chrome Android, but explicitly disabled (as documented in the not-webview-exposed.txt file). I'm wondering if the part of the documentation that says "This WebView does not have full feature parity with Chrome for Android" is referring to that?

[jpmedley]

No way to tell, but I doubt it. That was before Chromium started providing native-like features, so there were fewer reasons to deliberately break parity in those days. Joe Medley | Technical Writer, Chrome DevRel | [email protected] | 816-678-7195 *If an API's not documented it doesn't exist.*

…

On Fri, Dec 11, 2020 at 1:35 PM Queen Vinyl Darkscratch < ***@***.***> wrote: "It's known that WebView Android explicitly disables certain features. Perhaps that is what the documentation means, regarding WebView for Android 4.4?" I'm not sure what you mean by that. WebView lacks certain features because they're provided by the native app wrapper. Sorry, I'm bad at explaining things... What I mean is: there are several features that are in Chrome Android, but explicitly disabled (as documented in the not-webview-exposed.txt <https://source.chromium.org/chromium/chromium/src/+/master:android_webview/tools/system_webview_shell/test/data/webexposed/not-webview-exposed.txt?q=not-webview-exposed> file). I'm wondering if the part of the documentation that says "This WebView does not have full feature parity with Chrome for Android" is referring to that? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#7543 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6S7CYAUGMUNVOREJB75DDSUKGAZANCNFSM4UGLNOGQ> .

[ddbeck]

I don't think there's much more to discuss here, so I'm going to close this. Thanks everyone!