Page MenuHomePhabricator

Bump Firefox version in basic support to 3.6 or newer
Closed, ResolvedPublic

Description

Motivation

  • Persist / possibly improve user experience by enabling skin interfaces using of rem units, making them fully text zoomable by users with accessibility needs and do away with pixel based text and image sizing
  • Simplify design–development handover by doing away with close to incomprehensible em based sizing

See T262928: Use opinionated `rem` setting across Wikimedia Foundation deployed skins for more information on the negative effects of somewhat sticking to ems.

Note that the reality of supporting Firefox 3.0+ in MediaWiki core was not fully reflected for a while any more.
Firefox 3.5 was the first version to include crucial rendering and interaction properties like

  • media queries,
  • full ::before and ::after support
  • opacity instead of -moz-opacity property

which have been widely used in core.

Firefox 3.6 on the other hand has introduced rem support and additionally from the more often used properties background-size or pointer-events.

Proposal

I'm proposing to bump Firefox to at least v3.6+ in “Basic” in the browser support matrix. It was released Jan 21, 2010.

This would be effective in MediaWiki 1.36, to be released in 2021.

Statistics

Turnillo shows that use of Firefox 1-3 is approximately 580K per week across the wikis, with no particularly high usage in any given country. While this includes version 3.6 and falls well below the 1% threshold applied to other such decisions before, we've found out in process, that Wikimedia wikiprojects are limited to TLS 1.2+ since Jan 2020, see T238038 and therefore isn't accessible at all any more for Firefox lower than 27, including Firefox 3.

Event Timeline

Volker_E created this task.Sep 15 2020, 4:25 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 15 2020, 4:25 PM
ovasileva added a comment.EditedSep 29 2020, 1:01 PM

A quick look at Turnillo shows that use of Firefox 1-3 is approximately 580K per week across the wikis, with no particularly high usage in any given country. Based on this, I think we can go forward with the task as suggested.

Note that filter will also include 3.6+ so our target here is even lower than that. In relative terms it is <0.25% of FF users, and FF is about 13% of desktop or 5% overall, so <0.033% of desktop or <0.013% overall.

Krinkle added a subscriber: ema.Oct 1 2020, 8:20 PM

I suspect the Firefox versions in question are actually not able to access Wikipedia due to insufficient TLS/HTTPS connection protocol support. If true, then these entries are noise from bots or crawlers faking their user agent and/or from bugs in the ua-parser we use.

/cc Traffic @ema Do you know what our expected compat is with Firefox for our currently supported TLS ciphers?

Krinkle updated the task description. (Show Details)
Krinkle moved this task from P1: Define to P4: Tune on the TechCom-RFC board.
Krinkle moved this task from P4: Tune to P3: Explore on the TechCom-RFC board.

Outreach with Product and Traffic on-going.

It looks like we require TLS 1.2, which means anything less than Firefox 27 will fail to load. I verified this on crossbrowsertesting.com:

Here's the support matrix for TLS 1.2: https://www.caniuse.com/tls1-2

That matrix claims IE9/10 don't have TLS 1.2 enabled by default, but it can be enabled, as was enabled by default crossbrowsertesting.com & browserstack.com.

It probably doesn't make sense to continue MediaWiki support for browsers which Wikimedia doesn't serve to anymore.

This would mean bumping Grade C for the following browsers:

  • Firefox 27+
  • Chrome 29+
  • Safari 7+
  • Opera 16+
  • Android browser none (Chomium WebView only)

It looks like maybe we dropped TLS 1.0/1.1 in January: T238038

Izno added a subscriber: Izno.EditedOct 2 2020, 5:32 PM

Safari 7+

Which also bumps Safari grade A. A good chunk of the compatibility matrix to the right of the fast-release cohort could use some grade A review in general.

This would mean bumping Grade C for the following browsers:

Almost catches up to the versions in the handful of tasks for grade A support at T178356, T75714, and T237688.

@Izno You're right. But even if that's the case right now, there will be gaps in the future again.

While awaiting the final feedback from Traffic and @ema, point in case with the necessary TLS 1.2 support (second time verified of Wikipedia not being accessible by Safari 6.2 on OS X Mountain Lion) were to broaden this task with bumping the Grade A browsers to the list already shared by @Esanders in T262946#6512792
if we agree to intertwine MediaWiki support with Wikipedia traffic/ops support.

Right now, Firefox 3 basic support vs proposed 3.6 is holding current needs like relying on rem back. So I'm open for both ways, limiting the task to the current description or – personally leaning slightly towards – broadening it up to be more future-facing in our development limitations.

Izno added a comment.Oct 5 2020, 3:07 PM

@Izno You're right. But even if that's the case right now, there will be gaps in the future again.

Oh sure, just passively suggesting that it might be convenient to bump the majority of the items once rather than consider what is now 4 separate tasks of bumping.

broadening it up to be more future-facing in our development limitations.

(I still have been unanswered w.r.t. this thread about a standardizing discussion of supported browser versions rather than the ad hoc discussion that occurs now.)

@Izno You're right. But even if that's the case right now, there will be gaps in the future again.

While awaiting the final feedback from Traffic and @ema, point in case with the necessary TLS 1.2 support (second time verified of Wikipedia not being accessible by Safari 6.2 on OS X Mountain Lion) were to broaden this task with bumping the Grade A browsers to the list already shared by @Esanders in T262946#6512792
if we agree to intertwine MediaWiki support with Wikipedia traffic/ops support.

Right now, Firefox 3 basic support vs proposed 3.6 is holding current needs like relying on rem back. So I'm open for both ways, limiting the task to the current description or – personally leaning slightly towards – broadening it up to be more future-facing in our development limitations.

TLSv1.2 or TLSv1.3 are the only valid TLS versions to access Wikipedia. On January 16th We (Traffic) disabled TLSv1.0/TLSv1.1 support and enabled TLSv1.3 support on April 16th.

Please note that as part of T258405 we are deprecating the TLSv1.2 cipher suite ECDHE-ECDSA-AES128-SHA. As a result OSX 10.11 / Safari 9 (https://www.ssllabs.com/ssltest/viewClient.html?name=Safari&version=9&platform=OS%20X%2010.11&key=111) will be the minimum version supported to access Wikipedia

Mentioned in SAL (#wikimedia-operations) [2020-10-06T14:45:15Z] <vgutierrez> Bump ECDHE-ECDSA-AES128-SHA pageview replacement to 5% - T262946

Krinkle added a comment.EditedOct 7 2020, 1:29 AM
Task description:
  • Statistics: To be collected.

@Volker_E Which statistics would you like to document and use to inform this decision?

Would make sense to limit/widen the proposal to sync browser support for MediaWiki with WMF production traffic TLS requirements?

I suppose in that case we could do due diligence in verifying the stats are low and/or have explanations for existing. In my experience, data on TLS support tends to be flaky and contradictory at times since it's not always straight-forward how OS vendors and/or browser vendors update TLS protocols/chipersuites etc.

I can also see it being simpler to do just Firefox, depends on the third-party aspect I suppose. Your call :)

Volker_E updated the task description. (Show Details)Oct 14 2020, 5:57 PM

For quicker progress, I'd pledge for continuing with the simple bump of Firefox here to unblock using rem and solidifying CSS assumptions already made in our codebase and will file a task taking the TLS 1.2 impact and question on how we bind MediaWiki core to those browsers to a follow-up RFC.

Krinkle moved this task from P3: Explore to P4: Tune on the TechCom-RFC board.Oct 16 2020, 11:51 PM

Splendid. Is this good to go on Last Call next Wednesday?

Definitely from our side!

Milimetric added a subscriber: Milimetric.

This is now on last call, due to be approved on November 4th.

Cross-referencing https://caniuse.com/rem and https://www.mediawiki.org/wiki/Compatibility#Browser_support_matrix, to guarantee rem support the following have to be bumped as well:

  • Safari from 3 to 5
  • possibly Chrome from 1 to 4

Is this handled in this ticket as well or separately?

Tgr added a subscriber: Tgr.Oct 21 2020, 11:46 PM

I suspect the Firefox versions in question are actually not able to access Wikipedia due to insufficient TLS/HTTPS connection protocol support. If true, then these entries are noise from bots or crawlers faking their user agent and/or from bugs in the ua-parser we use.

Or workplaces / countries with man-in-the-middle requirements.

Here's a caniuse comparison tables:

The following are newly fully supported:

  • contenteditable attribute (basic support)
  • CSS3 Multiple backgrounds
  • querySelector/querySelectorAll

The following are newly supported, some with prefixes:

  • CSS3 2D Transforms
  • CSS3 Box-Shadow
  • CSS3 Background image options

The following are newly supported, some partially

  • CSS3 Media Queries
  • TTF/OTF - TrueType and OpenType font support

Note that rem support is not in any of these lists due to Safari 3 support.

Cross-referencing https://caniuse.com/rem and https://www.mediawiki.org/wiki/Compatibility#Browser_support_matrix, to guarantee rem support the following have to be bumped as well:

  • Safari from 3 to 5
  • possibly Chrome from 1 to 4

Is this handled in this ticket as well or separately?

Handled under impact of TLS 1.2 requirement at T266866: Bump basic supported browsers (grade C) to require TLS 1.2 for MediaWiki core and Wikimedia infrastructure alike.

SerDIDG added a subscriber: SerDIDG.Nov 7 2020, 1:08 AM

Approved per today's TechCom meeting and async confirmation on Wikitech.