Discussion: How to resolve Chromium true and null values

[jpmedley]

Pursuant to #3555.

At this point, I can write a nearly complete set of rules for version matching and I know exactly where the holes are.

• Chrome 1 - 18: Chrome Android becomes 18
• Chrome 19 - 25: Chrome Android becomes 25 (There were no Android versions labeled 19 to 24.)
• Features listed in both or neither not-webview-exposed.txt or global-interface-listing-expected.txt (webview files) are flagged for investigation.
• Features listed in the latter file match Chrome Android if it is 37 or later.

Here's the holes:

• I have no reliable source for the edge cases where Android and desktop don't match. I wish I could find a file in the config or build system that would give that information. So far I have not.
• I have no information regarding pre-Chromium webview. I am not likely to get any.

This is going to make some people unhappy, but one solution to the webview problem is to stop trying to capture pre-Chromium webview and add '37' to any Chromium features that landed in Chrome Android before 37. In other words, restrict webview_android to refer only to Chromium-based webviews.

[a2sheppy]

This is going to make some people unhappy, but one solution to the webview problem is to stop trying to capture pre-Chromium webview and add '37' to any Chromium features that landed in Chrome Android before 37. In other words, restrict webview_android to refer only to Chromium-based webviews.

While I understand the rationale, it sure would be nice to find a better way. That's a lot of data we lose if we go that route. I won't fight tooth and nail on this one, but as most of us know, I'm big on having all the data available, and never getting rid of information.

If the BCD community and @Elchi3 are okay with it and Google is okay with it, then I suppose that's fine. But it would be excellent to come up with a better answer.

[jpmedley]

Google is ok with it. That's not the bigger issue. The bigger issue is that we have no way of verifying existing data or filling in the gaps and we're not going to spend money to do that for products that are no longer supported or soon will be.

[a2sheppy]

Google is ok with it. That's not the bigger issue. The bigger issue is that we have no way of verifying existing data or filling in the gaps and we're not going to spend money to do that for products that are no longer supported or soon will be.

Sure, I get that. That leaves us with two approaches:

1. We decide we can't just ignore those versions. In this case, we need to determine what placeholder if any to specify in the meantime until such time as a contributor figures out the correct information and adds it, then make sure the presentation is useful in terms of explaining the versioning and why things are how they are (technology change, obsolete versions, etc).
2. We decide to do what jpmedley suggests and limit webview_android to covering the Chromium-based versions. We decide on exactly how to present this (essentially as he describes above, probably) and move on.
3. We decide to establish a "these versions may or may not exist but we do not cover them" data representation and/or presentation method.

While I prefer option 1 by a significant margin, it's not strongly enough to make a fuss over. Deciding between option 2 and option 3 is harder for me. I personally kind of feel that it would be more honest to devise a way to say "some versions in this range do exist, but no specific data is available."

[queengooborg]

Since this also applies to Opera, and soon Microsoft Edge, I think that something we should consider while coming to a conclusion regarding this is who uses the data, and for what purposes. Are we tailoring it to developers to provide better consumer experience on their websites? Or do the users of this data want the most robust data they can get? If it's the first, then most likely consumers won't be using pre-Chromium versions of Opera or Webview (and if they are, they must have heavily outdated hardware), and limiting the data to Chromium-based versions may be the way to go.

Personally, I'm leaning towards option 2 for the simple reason that pre-Chromium Webview is considered obsolete, and obtaining new data for its features does not sound like an option based upon @jpmedley's statement, though I'm skeptical about the removal of data for any reason. I don't feel strong enough about my choice to say that we have to do it that way, though -- whatever outcome is decided, I'll support. 🙂

Edit: looks like we've chosen option 1 with the inclusion of ranged values, which now that I look back at it, makes sense!

[a2sheppy]

Everyone that knows me at all knows I’m a big believer in having the most thorough data set possible. The notion of including the pre-Chromium Opera makes me all cringey. I can live with it for pre-Chromium WebView, since Google particularly doesn’t want that data out there, but I admit I personally wish it were otherwise. :) On March 20, 2019 at 3:57:33 PM, Vinyl Darkscratch ([email protected]) wrote: Personally, I'm leaning towards option 2 for the simple reason that pre-Chromium Webview is considered obsolete, and obtaining new data for its features does not sound like an option based upon @jpmedley's statement <#3561 (comment)>, though I'm skeptical about the removal of data for any reason. I don't feel strong enough about my choice to say that we have to do it that way, though -- whatever outcome is decided, I'll support. 🙂 Eric Shepherd Senior Technical Writer MDN Web Docs <https://developer.mozilla.org/> Blog: https://www.bitstampede.com/

[jpmedley]

If we remove the data, it won't be gone. If compat data were still wiki text, it would be. Anyone who wanted to resurrect old data from this repo would be able to check out a particular commit hash (git checkout commit-hash). We could add a git tag to make it easy to find the point to check out.

Regarding Microsoft, I had some discussions with someone from MS in January about what they're actually going to do. (I believe Chris was in the room.) It sounds as though they may need to treat their Chromium-based browser as a separate piece of software, at least for a while. I strongly suspect this has to do with enterprise contracts that specify Edge. At the very least this is something to check in to. If Chromium and non-Chromium edge exist side-by-side for any length of time, that makes following WebView plan difficult if not impossible.

[a2sheppy]

On March 20, 2019 at 4:14:18 PM, Joe Medley ([email protected]) wrote: If we remove the data, it won't be gone. If compat data were still wiki text, it would be. Anyone who wanted to resurrect old data from this repo would be able to check out a particular commit hash (git checkout *commit-hash*). We could add a git tag to make it easy to find the point to check out. That’s a fair point, although the data would not be easily accessible in a simple tool that uses a single source of truth. But that’s neither here nor there. This particular aspect of the discussion is pretty much over, so what we need to figure out is how to best flesh out the remaining data we’re missing. Regarding Microsoft, I had some discussions with someone from MS in January about what they're actually going to do. (I believe Chris was in the room.) It sounds as though they may need to treat their Chromium-based browser as a separate piece of software, at least for a while. I *strongly* suspect this has to do with enterprise contracts that specify Edge. At the very least this is something to check in to. If Chromium and non-Chromium edge exist side-by-side for any length of time, that makes following WebView plan difficult if not impossible. That sounds plausible. It’s how I’d do it in their shoes. Eric Shepherd Senior Technical Writer MDN Web Docs <https://developer.mozilla.org/> Blog: https://www.bitstampede.com/

[queengooborg]

Since we've taken care of almost all true/null values for Chromium, and we have a mirroring script that takes these guidelines into account, I think it's safe to close this issue now!