Page MenuHomePhabricator

RFC: Remove Android 2 from basic support in compatibility matrix
Closed, ResolvedPublic

Description

  • Affected components: MediaWiki core, skins and extensions.

Motivation

This RFC is split out of T248061. On the mobile site, Android 2 is not supported any more and respectively not mentioned in mobile support section of Compatibility article.

  • Improve the user experience by making pages load slightly faster and use less bandwidth, because we'd send less CSS code down the wire.
  • Take away maintenance-burden of writing fallback CSS for newer CSS features not supported in Android 2. The effort spent here is a waste of our limited resources.
  • Unlock use of newer CSS features that do not have a fallback and thus cannot be safely used today.

Features we would no longer consider optional or need fallbacks for:

  • SVG background icons (no need to generate PNG fallbacks, and referring them, therefor reducing CSS size sent to all clients by a significant amount).
  • position:fixed (caniuse, Wikimedia deployed)

Proposal

I'm proposing to remove Android 2.0+ (2.1-2.3) from “basic” support in the desktop compatibility matrix.

Statistics

Android 2 doesn't play a role in desktop at all, and has not been visible in our analytics.wikimedia.org for a while (it's under the 0.1% cut off as of October 2019).

Wikimedia sites currently receive about 36 million requests from Android 2 devices per month. About 60% of these are visits to the www.wikipedia.org portal, and the rest about evenly between the mobile and desktop domains.

For the desktop domains and Wikipedia portal, the traffic is mainly from USA, Canada, Brazil, Ireland and France. Our mobile site has officially already dropped basic support ("Grade C") for Android 2. Details at T249788#6060612.

Event Timeline

@Volker_E wrote

Statistics. Android 2 doesn't play a role in desktop at all, and has not been visible in our statistics for a while.

Indeed. It's under 0.1% globally which means our public dashboards at analytics.wikimedia.org don't show it anymore as of October 2019.

Querying Turnilo directly, I see that we got about 36 million requests from Android 2 devices in the last 30 days (283,000 in the 1/128 sampling), which is about 1 million requests per day. These break down as:

  • (portal site) www.wikipedia.org: 610,000/day (143K samples)
  • (mobile site) en.m.wikipedia.org: 98,000/day (23K samples)
  • (desktop site) en.wikipedia.org: 76,000/day (18K samples)
  • (mobile site) fr.m.wikipedia.org: 36,000/day (8.6K samples)
  • (desktop site) es.wikpedia.org: 6,400/day (1.5K samples)

Given the mobile site has officially already dropped support, only breaking down portal and desktop further by country.
Android 2 devices visiting portal and desktop sites (rounded down to nearest thousand):

  • United States: 588,000/day
  • Canada: 41,000/day
  • Brazil: 32,000/day
  • Ireland: 31,000/day
  • France: 23,000/day
Turnilo
Screenshot 2020-04-15 at 23.30.16.png (746×937 px, 53 KB)
Screenshot 2020-04-15 at 23.32.47.png (925×1 px, 101 KB)
@Volker_E wrote

[…] pages load slightly faster, because we'd send less CSS code down the wire.

Can you mention a just a few CSS properties as example that we use today in our base styles that could be removed from our codebase as result of dropping Android 2 support for desktop?

@Krinkle Added the two most commonly known limitations, with PNG fallbacks also impacting question around IE 8 removal from Grade C.

@Volker_E - Could you explain how SVG background icons or position:fixed fallbacks are necessary for preserving core functionality in MediaWiki (i.e. reading, searching, editing) on Android 2? In other words, what specific feature(s) would be broken? I'm asking because I'm wondering if we could just remove these 2 fallbacks anyway (regardless of Grade C support).

+1, from the perspective of a helps hosts of a mediawiki farm, We get very few android 2 users and the site was very slow in testing by someone else. On some devices I picked, I found even Grade As produced TLS errors on our farm. The ones on Grade A I could get worked, no grade Cs were accessible on both Miraheze and English Wikipedia.

Progressing further in the process.

@kaldari Are you able to approve this on behalf of Product?
@Volker_E See above question, also is there anyone (else) you're waiting to hear back from?

Has anyone noticed that most of OOUI's fallback PNGs are broken anyway?
Help icon:

help.png (20×20 px, 244 B)

Edit pencil:
edit.png (20×20 px, 326 B)

Eyeball (for VE):
eye.png (20×20 px, 312 B)

@kaldari Are you able to approve this on behalf of Product?

To get back to Krinkle's question, the only features that I'm worried about supporting for Android 2 are reading and searching. The only UI elements that are needed for those are the search button (magnifying glass) and the close button (x). Is it possible for us to retain PNG fallbacks for just those two buttons (which I believe are mediawiki-ui buttons rather than OOUI buttons anyway)?

I believe what you're describing is essentially what Grade C / Basic support represents. For reading and seaching to work, you'd also need MediaWiki core and our infrato not crash or break the HTTP connection to the browser, and you'd need the skin overall to render the page layout in a way that doesn't cause other features to overlap or interfere with the two you describe.

On an individual feature level, individual PMs can already decide to make features invisible or excluded from the default guideline. For example, VisualEditor and MobileFrontend have historically had their own support matrixes.

@kaldari Can you confirm that you're focussing on Android 2 browsing the mobile site? (As opposed to "Desktop view" / canonical domain).

@Volker_E It sounds like you're working on the assumption Android 2 is already not supported by the Reading team for MobileFrontend, and thus want this RFC to also drop it from basic support from MediaWiki core, WMF infrastructure, and lower-level libraries we maintain. Is that right? When the Mobile browser matrix was last updated on mediawiki.org in (permalink, Oct 2019) it still mentioned Android 2.

@Krinkle - Yes, I was only talking about Android 2 on the mobile site.

Krinkle renamed this task from RFC: Remove Android 2.0+ from basic support in compatibility matrix for Desktop to RFC: Remove Android 2.0+ from basic support in compatibility matrix.Apr 29 2020, 11:27 PM
daniel subscribed.

Per the discussion in yesterday's TechCom meeting, I'm moving this to Last Call. If no relevant concerns remain unaddressed by May 13, this RFC will be approved as proposed.

Querying Turnilo directly, I see that we got about 36 million requests from Android 2 devices in the last 30 days

@Krinkle - How is 36 million requests per month less than 0.1% of traffic? That seems like it should be about 0.2% of traffic unless my math is wrong.

I've surveyed a bunch of folks in Product and there are no objections to moving this forward as proposed. Pending an answer to the question above, I'm prepared to sign off on this on behalf of Product.

@Krinkle - How is 36 million requests per month less than 0.1% of traffic? That seems like it should be about 0.2% of traffic unless my math is wrong.

It's under 0.1% globally which means our public dashboards at analytics.wikimedia.org don't show it anymore as of October 2019.

Querying Turnilo directly, I see that we got about 36 million requests from Android 2 devices in the last 30 days (283,000 in the 1/128 sampling) […]

The analytics.wikimedia.org browsers dashboard has a cut-off of 0.1% and is generated weekly. For Turnilo, I did a query over 30 days. Also note that the Turnilo data is 1/128 sampled, so it may be off by a few points for something that is small overall.

Got it. Thanks for walking me through that. Product has no concerns about discontinuing basic support for Android 2.

Krinkle renamed this task from RFC: Remove Android 2.0+ from basic support in compatibility matrix to RFC: Remove Android 2 from basic support in compatibility matrix.May 13 2020, 8:22 PM

Per the discussion in yesterday's TechCom meeting, I'm moving this to Last Call. If no relevant concerns remain unaddressed by May 13, this RFC will be approved as proposed.

@daniel - Can this RFC be considered approved now?

Milimetric subscribed.

Yep, sorry we forgot to wrap this up last week. Per the process, this is now approved.