Page MenuHomePhabricator

<Core Technology> Organize Process for Browser Degradation Requests
Closed, InvalidPublic

Description

Request Status: New Request
Request Type: project support request
Related OKRs: P-PPL

Request Title: Proposal for Browser Support

  • Request Description: There is documentation on MediaWiki for browser compatibility that explains which browsers are currently supported and to what degree. Requesting changes to supported browsers requires an RFC, but without a template and guidelines for requesting browser degradation we end up spending a lot of time tracking down affected teams, analytics and product managers. It would be helpful to streamline the process, either as an FTR or on MediaWiki where stakeholders can subscribe to proposals and decisions can be logged.
  • Indicate Priority Level: High
  • Main Requestors: Design Systems Team
  • Ideal Delivery Date: Q3 2022
  • Stakeholder Teams: Design Systems, Readers Web, Growth, Platform Product

Request Documentation

Document TypeRequired?Document/Link
Related PHAB TicketsYesT289017
Product One PagerNo
Product Requirements Document (PRD)No
Product RoadmapYesDesign Systems Roadmap
Product Planning/Business CaseNo
Product BriefNo
Other LinksYesMediaWiki compatibility info

Event Timeline

STH triaged this task as Medium priority.Dec 23 2021, 7:37 PM
STH created this task.
STH added a subscriber: dr0ptp4kt.
STH removed Catrope as the assignee of this task.Jan 6 2022, 3:03 PM
STH added a subscriber: Catrope.

It would be good to have a policy for this, but on the practical side I don't foresee another major version upgrade (like v2 -> v3) happening for quite some time.

Vue and its related libraries follow a slower pace of "major" releases than say React and related libraries do.

For now I think it would be okay to say that we'll follow 3.X minor upgrades and 3.X.x patch upgrades as needed (addition of new features, security fixes, etc); for any future major upgrade (4.X, meaning breaking API change) I think we can evaluate as a special case.

I refer to Vue above but this policy would likely also work fine for all related official projects (Vuex, Vue-test-utils, Vue-Router, etc). In the React ecosystem things are a lot more de-centralized and many different third-party plugins will iterate at different rates; in the Vue world there is a smaller number of key projects but they tend to change at a similar pace.

2022/02/16 Product Implementation Steering Committee Notes

  • @STHART will be running point on this ticket going forward
  • Legacy Browser Support - previous perspective was that it is okay to build javascript user experiences, but the open question is if there is a downside to modernization for power users
    • Growth team's approach: make it possible for basic activities (reading, editing, etc.) but not for more modern features/experiences
    • Did we do an analysis of anyone getting impacted by deprecation of IE11?
      • Power users - turn off java script
      • Software engineers - want to run js in command window
  • For larger issues the community normally would bubble it up, but so far we have not heard anything related to this topic
  • @dr0ptp4kt will talk with @STHart . @SCherukuwada has found good ways to talk to Timo and Olga has been involved
DAbad renamed this task from Define Criteria for Vue.js Version Support in MediaWiki to <Product Intitiative> Define Vue.js Version Support in MediaWiki.Feb 16 2022, 1:41 PM

Regarding IE11 (and other non-ES6-capable browsers), I just want to say that downgrading Vue back to v2 is not very feasible at this point. Codex is written from the ground up in Vue 3 (which is not compatible with IE11), and the migration process from v2 -> v3 is underway for all other Vue.js features in MediaWiki.

The decision to allow new JS features to drop support for legacy browsers like IE11 came out of a Product department discussion in late 2020/early 2021 (led by Jon Katz), and was re-affirmed in last summer's Developer Summit (see T286947; this was one of the key questions we set out to resolve). More documentation from this part of the summit discussion can be found here.

We can continue to support users of legacy browsers by providing solid non-JS interfaces as a fallback, wherever a team deems necessary. This approach also has other benefits (some users of modern browsers also disable JS for various reasons, and providing a no-JS UI can be helpful for performance and SEO). I think this is compatible with what the Growth team is considering – ensure core functionality is available without JS, but some enhancements or non-critical features may require it.

Commons MediaSearch (one of the first big Vue features) uses a similar approach – there is a robust no-JS version of the UI that legacy browsers and no-JS users will get; everyone else gets the Vue-based experience.

I do hope we can refine (and document) this policy – it will help us resolve some related questions like T289208.

STH renamed this task from <Product Intitiative> Define Vue.js Version Support in MediaWiki to <Product Initiative> Proposal for Browser Support.Feb 18 2022, 7:27 PM
STH raised the priority of this task from Medium to High.
STH updated the task description. (Show Details)

Staff members working on MediaWiki should have a clear policy on legacy browser support and what experiences must be supported on legacy browsers. Having this policy will help us maintain our commitment to using modern software and allow us teams plan ahead for migrations so they are minimally disruptive. Like the support policy for PHP, the browser support policy should not require an RFC for browser deprecation decisions.

Mediawiki's official browser support policy is described here: https://www.mediawiki.org/wiki/Compatibility#Browsers. There is also a long-standing Phabricator task around raising the requirement for all JS support (new or existing features, Vue-based or not, etc) to ES6 – see T178356. I see the work that has been done so far around Vue 3, ES6 support, and IE11 deprecation (for new, JS intensive features) as a step in this direction.

I think it would be good to connect the various conversations around when/where to use Vue, what baseline level of JS MediaWiki needs to support, what level of no-JS fallbacks should exist for various features, etc.

STH renamed this task from <Product Initiative> Proposal for Browser Support to <Core Technology> Proposal for Browser Support.Feb 22 2022, 8:57 PM

I think it would be good to connect the various conversations around when/where to use Vue, what baseline level of JS MediaWiki needs to support, what level of no-JS fallbacks should exist for various features, etc.

Agreed. Here's how I've been approaching the tasks so far -

This task will address the baseline level of JS MediaWiki needs to support and what level of no-JS fallbacks should exist for various features. Those questions are framework-agnostic and we can base decisions on where/when to use Vue around the answers.

I created T302351 (Proposal for Vue.js/Codex Development & Performance Guidelines) to capture Vue-specific blockers, which was meant to clone and track the output of T289208 (Develop and document a proposal for when to use Vue/Codex.). I'm now realizing that the titles aren't aligned, but they're both getting at guidelines for frontend development concerns as they relate to Vue specifically so I think it would make sense to use the Foundation ticket title for both.

Both of these open questions around browser support and Vue development are blockers for design system adoption and are equally important. I think we can parallel path on both of them. I'd like to complete both of these proposals in Q4.

For this browser support task, next steps I'm going to take are:

  • Searching for data on IE11 usage and user impact (I'm going to request access to Turnilo and talk to the analytics team, let me know if you have other suggestions)
  • Connect with Growth team to learn what "basic activities" outside of reading/editing are currently supported by legacy browsers
  • Connect with other teams to understand what features they currently deem necessary to have in IE11, and why, and cross-check with data
STH changed the task status from Open to In Progress.Mar 2 2022, 8:14 PM
STH renamed this task from <Core Technology> Proposal for Browser Support to <Core Technology> Browser Degradation Approval Process .Mar 14 2022, 2:25 PM
STH updated the task description. (Show Details)

Requests being considered for the next version of MediaWiki (this week):

  • Remove IE9 & IE10 from basic support T293298
  • Bump basic and modern supported Android browsers to v5 T290815
  • Move Firefox 27-38 from Basic support to Unknown support T297313
STH renamed this task from <Core Technology> Browser Degradation Approval Process to <Core Technology> Browser Degradation Requests to be Foundational Technology Requests.Mar 17 2022, 1:37 PM
STH updated the task description. (Show Details)

Design Systems, Readers Web, Growth, and Analytics teams are in support of moving forward with the request to stop MediaWiki testing/support for IE9, IE10, Firefox 27-38, and Android browsers below v5. We will move forward with pushing this through for the next version of MediaWiki.

Key factors in the decision:

  • Downgrading IE9, IE10, and Firefox 27-38 from Basic Support to Unknown Support has no bearing on peoples' ability to use Visual Editor, considering VE is already not available to those versions
  • Only 0.000025% of edit attempts in the past year were from users with Android browsers below v5 (roughly 300 out of 16 million) so loss of this functionality is not significant and benefits of improved performance vastly outweigh the cost
  • The analytics team affirmed that recent increases in traffic from IE9, IE10, and Firefox 27-38 starting on Feb 23, 2022 is coming from bots
From the task description:

Related OKRs: P-PPL

I'd like to know what this means. I did a quoted search for "P-PPL" on mediawiki.org as well as Meta-Wiki, which yielded no results.

In T298268#7786950, @STHart wrote:

[…] loss of this functionality is not significant and benefits of improved performance vastly outweigh the cost

Which performance improvement is this referring to? I could not find mention of it within this task or its comments.

An update based on feedback from downgrading IE9/10 support:

Since there are many downstream MediaWiki stakeholders for this decision-making process, the "source of truth" for this process might be better placed on a MediaWiki page for decisions/logs that people can subscribe to. It could live adjacent to https://www.mediawiki.org/wiki/Compatibility. Will update the task (including OKRs, will grab a proper description - that one is a catch-all for Platform work - thanks @Aklapper)

In T298268#7885127, @STHart wrote:

An update based on feedback from downgrading IE9/10 support:

Since there are many downstream MediaWiki stakeholders for this decision-making process, the "source of truth" for this process might be better placed on a MediaWiki page for decisions/logs that people can subscribe to. It could live adjacent to https://www.mediawiki.org/wiki/Compatibility. Will update the task (including OKRs, will grab a proper description - that one is a catch-all for Platform work - thanks @Aklapper)

Yup, that's https://www.mediawiki.org/wiki/Template:Compatibility_browser right now and I think it should continue as such.

STH renamed this task from <Core Technology> Browser Degradation Requests to be Foundational Technology Requests to <Core Technology> Organize Process for Browser Degradation Requests.May 1 2022, 1:15 PM
STH updated the task description. (Show Details)