List Chrome for Android ahead, like Desktop?

[Schweinepriester]

As there is a Beta (https://play.google.com/store/apps/details?id=com.chrome.beta, currently 55) and a Canary version (https://googlechromereleases.blogspot.de/2016/10/introducing-chrome-canary-for-android.html => https://play.google.com/store/apps/details?id=com.chrome.canary) of Chrome for Android, what about listing it ahead like the desktop version? Maybe even Android Browser, too?

Could be usefull, e.g. for a pull request for #2925.
Or is Chrome for Android synced with Chrome when updating or the like?

[Fyrd]

Sure, could do that. Mostly I'm not much in a rush to do this because 90% of the time the information's the same as Chrome Desktop and it just adds more work for little value.

[stof]

same than #3518, right ?

[Schweinepriester]

@stof tho alike, not exactly: this one requests future (beta, canary) versions while #3518 requests previous ones…

[atjn]

Just wanted to chirp in and say that it is a pretty big deal with the WebXR spec. Many of the features are out earlier on the Android version, and they have very different quirks that i would have liked to reflect when i updated the data.

@Fyrd I am having a hard time accepting the argument that it would give "little value". Chrome for Android is currently the most used browser on the planet, so missing a small discrepancy in how it works can have huge consequences for a website.
A very useful feature in caniuse, is usage-relative view. Currently, it seems like all Android phones are up to date with the latest version, so it is easy to forget that there is a (possibly sizeable) user-base that dont have the new version, because they are being covered up and shown as if they do have the latest version.

I am both arguing for listing the versions ahead, but also backlogging (#3518).
Have you considered a model where we could add information only when it is different from desktop, and otherwise it would just fall back to the way it works right now? or fall back to just mirroring chrome for desktop?

[Fyrd]

@antonjuulnaber Yeah, I do actually have some code sitting around that does what you suggest, mirrors another browser's version unless otherwise specified. At some point I'll get back to that and we'll have a better way of dealing with "mostly the same" browsers.

[jpmedley]

Mostly I'm not much in a rush to do this because 90% of the time the information's the same as Chrome Desktop and it just adds more work for little value.

I'm not sure this is true. The soon to be released results of the MDN developer survey (which I got a sneak peak at) indicates that a significant portion of developers do not know that browsers have versions. They seem to think that the numbers in MDN's compat tables are market share.

If a developer doesn't know that browsers have versions, can we expect them to know that desktop and mobile have feature parity?

[Schweinepriester]

Off topic:

The soon to be released results of the MDN developer survey (which I got a sneak peak at) indicates that a significant portion of developers do not know that browsers have versions. They seem to think that the numbers in MDN's compat tables are market share.

I'm very much looking forward to those results. Hard for me to comprehend how developers dont know versions, as its the very thing they are working on: increments of software. Esp. in the context of the web, where you have to or at least strongly should consider browser support including versions… oO

[jpmedley]

I have that problem too. The presumed answer from everybody seems to be that it's because evergreen renderers like Chromium and Gecko are ubiquitous.

[kiding]

Thanks, @Schweinepriester! Let me come back to this PR once Chrome for Android 88 gets released.