| Nirmos | |
| Oct 17 2017, 9:06 AM |
| F36932731: IMG_4950.jpg | |
| Thu, Mar 30, 2:40 AM |
| F36932730: IMG_4949.jpg | |
| Thu, Mar 30, 2:40 AM |
| F36932693: IMG_4948.jpg | |
| Thu, Mar 30, 1:14 AM |
| F36932694: IMG_4947.jpg | |
| Thu, Mar 30, 1:14 AM |
Following T128115 which was resolved in April 2017, the next logical step would be to drop support for ES5 when the proportion of browsers in use that don't support ES6+ is low enough.
Note, for IE11 as biggest affected browser by user share, we've already set out to have special treatment for new features in March 2021.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T288287 Remove IE11 from Basic support ("Grade C") | |||
| Open | Jdforrester-WMF | T178356 Raise Grade A JavaScript requirement from ES5 (2009) to ES6 (2015) | |||
| Resolved | Catrope | T272104 Allow modules to opt-in to ES6 syntax support | |||
| Resolved | Catrope | T272882 Upgrade ResourceLoader JS minifier to support ES6 | |||
| Resolved | Catrope | T277085 Add support for ES6 client code to eslint-config-wikimedia | |||
| Resolved | Jdforrester-WMF | T333354 Announce Grade A JavaScript requirement rising from ES5 to ES6 |
From my point of view, there is only one feature on our platform of which I can say that it 1) implements a high core value, and 2) makes use of JavaScript, and 3) does not have a Basic layer or its fallback has a signficantly smaller potential audience (i.e. alienating, or requires significantly more expertise/barrier to entry). That feature is VisualEditor.
Once we have approval from @ppelberg (Editing PM) that they're ready to discontinue IE11 support, then this can move ahead as far as I'm concerned. If there are other significant platform capabilities without a Basic experience, please point the appropiate team to this ticket so that we can plan ahead, e.g. by adding the missing pieces for it to work at the Basic layer.
To summarise our general strategy: The mission values wide audience reach above all else (through Compatibility). We achieve that with high performance and high accessibility, at relatively low cost. We keep maintenance low and velocity high for developers by being aggressive in our JavaScript and Grade A support, thus allowing developers to leverage relatively modern code natively on the web, and reduce the number of browsers developers need to be familiar with and contiously test on, and avoid much of the potential for missing or buggy ECMAScript and Web APIs. All that without leaky, slow or fragile abstractions (e.g. compiling new syntax, where new methods remain undefined). This is made possible by having a solid Basic layer that everybody enjoys, with an optional and asynchronous JavaScript layer that may enhance it. (See Wikitech doc for wide ranging examples where JS is unavailable, even on modern devices.)
The dropping of ES5 being suspended for 5+ years is upending this equation, and thus understandably put pressure on (intentional) cost-benefit trade-offs that are meant to be rare instead of common. E.g. selecting and maintaining up-to-date polyfills, potentially having to incorporate complex feature checks into products, developers remembering which DOM/ES methods exist in decade-old browsers, etc. We've aided this through linting with eslint-plugin-compat, and with es6 mode in ResourceLoader to an extent, but these kinds of investments are meant to be rare or even non-existent for most teams. The faster we can move to ES6, the better!
Assuming that Editing is ok with officially dropping IE11 from Grade A support, should we just go ahead and drop it from Basic support too? See T288287: Remove IE11 from Basic support ("Grade C").
From my point of view, there is only one feature on our platform of which I can say that it 1) implements a high core value, and 2) makes use of JavaScript, and 3) does not have a Basic layer or its fallback has a signficantly smaller potential audience (i.e. alienating, or requires significantly more expertise/barrier to entry). That feature is VisualEditor.
Page previews would also meet this criteria so I think this also needs approval from @ovasileva.
Once we have approval from @ppelberg (Editing PM) that they're ready to discontinue IE11 support
Page previews would also meet this criteria so I think this also needs approval from @ovasileva.
I'm not sure we've had input before from PM's in dropping browser support. There are plenty of teams that would be affecting by a browser dropping from Grade A to Grade C, nor do I expect PMs to have specific knowledge on the impact to their projects.
From a technical point of view we haven't tested VE in IE11 for years, just relied on bug reports, so if it is still being used by editors it is probably quite buggy. Also editors tend to have more modern browsers than readers so the 0.0-0.1% estimate for IE11 usage is probably high for editors.
The bigger impact is going to be the amount of compatibility code we can drop, and from this perspective I give my support.
We already stopped fundraising banners displaying in IE11 (both for developer productivity, and since some payment providers don't support it), and are about to start requiring ES6. So no objections from a Fundraising pov.
Other CentralNotices would be impacted by this, but I don't think it's a major concern given the small portion of users affected.
Design System Team has agreed on that it would be beneficial that
Graphs don’t render at all without JavaScript since T236892: Communicate transition of Graph/Graphoid to client-side only JavaScript feature. I don’t know what the responsible team is, but they don’t even seem to really want to fix it.
The GOVUK Frontend design system are also working on dropping IE11 support. Their work highlighted an issue that I think affects us as well. Upstream details at https://github.com/alphagov/govuk-frontend/issues/2718, summarised below.
I suggest revising our "current and previous" to be:
With IE11 gone from the Grade A browser matrix, there will become a significant gap between our effective feature-test (i.e. in how wide a range of browsers we opt-in to Grade A) and what we document in our guidelines as a supported browser. The reason the gap is fairly small today is because IE11 is effectively a proxy for many previous releases of Firefox and Chrome.
We've been documenting for many years that we support "Current and previous versions", based on the "evergreen" and automatic upgrades that developers generally believe in today. While true that all major browsers apart from Mobile Safari are, generally, performing automatic upgrades between any two versions, there are plenty of exceptions and these upgrades are by no means instantaneous. This is important
but, this seems very unlikely to be a fair and representative quantity to realistically limit our treatment of issues affecting Grade A browsers to.
For example, Chrome Mobile's share (at analytics.wikimedia.org) is 31%. Its current major version is 111 (released 2023-03-07), which makes up 4% and the previous version makes up another 19%, that's only about 2/3rds of its users.
Last week's usage numbers from analytics.wm.o add up as follows:
| Browser | documented | reality (per startup.js, ignoring Grade X) |
|---|---|---|
| Chrome Mobile | 23.5% (curr+prev) | 31% (13+) |
| Chrome | 15.5% (curr+prev) | 19% (13+) |
| Chrome Mobile iOS | 2.1% (curr+prev) | 2.2% (13+) |
| Firefox | 3.5% (curr+prev) | 3.7% (4+) |
| Firefox Mobile | 0.5% (curr+prev) | 0.5% (4+) |
| Opera | 0.5% (curr+prev) | 0.6% (15+) |
| Edge | 3.3% (curr+prev) | 3.5% (any) |
| Safari | 3.5% (9.1+) | 3.5% (9.1+) |
| Mobile Safari | 20% (9+) | 20% (9+) |
| total | 72.4% | 84.0% +12.4% |
| Other (presumed) | 9.2% | 11% |
| total (presumed) | 81.6% | 95.0% +13.4% |
Note that there is also a very big portion of "Other" non-bot traffic of 11% globally, that's a separate and known issue due to how we currently parse UAs, it's likely under-reporting the above due to an outdated ua-parser version or perhaps failing to attribute variants to their more common distributions (e.g. Brave, Samsung Internet, Chromium, etc.). We could tentatively assume a similar ~16% gap (72.4*1.16=84) in the "Other 11%" population.
The above suggests that our gap is about 1 in 9 pageviews globally, that's 2.3 billion monthly pageviews of 23B (per stats.wikimedia.org) or approximately 200 million uniques of 2B uniques last month on Wikipedia projects (per stats.wikimedia.org).
I suspect there are roughly three major causes for why "current + previous" has very poor coverage in practice:
Note for example that our own CI pipeline realises Firefox test coverage through an ESR version that is ostensibly not under Grade A supports. Similarly, our own use of Chromium in production such as for PDF rendering uses the Debian LTS distribution, and WMF employee Thinkpad laptops that run Ubuntu or some other Linux distro very likely default to an older Firefox and Chrome as well which are similarly not covered by the current "Grade A" policy.
most corporate/enterprise-managed devices
This is probably the biggest reason. +1 to everything above, current and previous has always been a lie and should be fixed. Updating our linting tools around newer definitions of Chrome/FF support should be a blocker to removing IE11 support.
Is this stuck waiting for a specific person/team to weigh in, or are we just in decision-maker paralysis? If the latter, I'm happy to just Declare It So, but I don't want to tread on others' toes.
From a ResourceLoader perspective, I delegate largely to product teams to indicate readiness. I indentified stakeholders in this comment a few weeks ago:
To my knowledge, every time in the past ~15 years when we've had a task like this, it generally involved a Director and/or PMs. E.g. Jon Katz on dropping many old browsers for TLS 1.2 in 2021 (T266866), Kaldari on dropping Android 2 from Basic (T249788), Olga on removing IE9 from Basic in 2021 (T293298). Before that it sometimes even involved an RFC where in turn we also consulted PMs for the decision.
OK.
Change 902706 had a related patch set uploaded (by Jforrester; author: Jforrester):
[mediawiki/core@master] [WIP] Raise MW JavaScript requirement from ES5 to ES6
@Jdforrester-WMF just an FYI that the Design Systems Team has already started drafting a comms plan around dropping IE 11 from basic support (T332716). We wanted to do a bit more digging into the data in (T331463) first. Let's just make sure to coordinate here so there isn't duplicated effort/mixed messaging.
@CCiufo-WMF Sounds good to me. Note that this task is for dropping Modern support ("Grade A"). Basic support ("Grade C") is a next step and we'll make sure to wait with that until DST are ready for it. I see no rush on that one. That work is tracked under T288287, which is already marked as requiring the DST spike to complete first (T332716).
Tech News entry last time was Some older [[w:en:Web browser|web browsers]] will not be able to use [[w:en:JavaScript|JavaScript]] on Wikimedia wikis from this week. If you have an old web browser on your computer you can upgrade to a newer version.; I think we can just re-use as-is.
If you have an old web browser on your computer you can upgrade to a newer version.
It’s not true. For example, if someone is stuck on Windows 2000, they can’t update to a supported browser version, as IE6 and Opera 12 have already long been unsupported, Chrome never supported 2K, and now Firefox 12 and lower also go out of support.
I’d write
If you have an old web browser on your computer, you should try upgrading to a newer version.
@Tacsipacsi The announcement is not about browser support in the abstract. It is about the specific set of browsers we are removing support for in this task. I agree that people on certain operating system versions cannot migrate to a newer browser, IE6 being an important historical example.
This task is specifically about IE11 and iOS 9 only. (We removed Grade A support for IE6-10 and iOS upto 8 several years ago.) The question is, are there Windows versions where these are the latest possible vesions available? And with no other modern browsers that support that version? Or are there Apple devices that support upto iOS 9 but not iOS 10? In my experience, most versions do not become historical cut-off points like IE6, so the answer is not an obvious "Yes" unless we have counter examples.
Looking at IE11, this was available from Windows 7 to Windows 10. These versions have access to newer alternatives (per Wikitech) in the form of recent Firefox and Chrome versions (less than 1 year old), or (if their computer supports a newer Windows) by using MS Edge.
Currently the two browsers+versions we still see page views from that don't have at least 95% implementation of the spec according to CanIUse (pageviews from Dashiki via https://steve-adder.toolforge.org/ via legoktm) are IE11 (0.107%) and apparently Opera Mini (0.078%) (numbers are a couple weeks old). We should name those directly in the user message.
Some older [[w:en:Web browser|web browsers]], IE11 and Opera Mini among others, will not be able to use [[w:en:JavaScript|JavaScript]] on Wikimedia wikis from this week. If you have an old web browser on your computer you can upgrade to a newer version.
The instruction to upgrade may not be true for Opera Mini. I think it's reasonable to change the message to something along the lines of Tacsipacsi's comment, and something like "or you can try using a different browser".
Separately, I think it would be a good idea to add that removal from grade A is happening Soon to https://www.mediawiki.org/wiki/Compatibility/IE11 also as a pointer for the IE11 part of the message, the link to which has previously been advertised.
Opera Mini is a "proxy" browser, which is essentially an app that displays data from a remote cloud server where the real browser runs. As such, the JS interactions there are quite different and not as user friendly. We moved Opera Mini to Grade C in 2013 (change), which means the JS layer is already disabled there.
This task is only about the optional Grade A JavaScript layer, not Basic access, thus it makes no difference to Opera Mini.
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/902706/ drops support for many more browser versions (at least according to the comment updates), among others Firefox 4–53 (Firefox 4 was supported on Windows 2000, Firefox 54 isn’t). The Tech News entry should highlight the actual changes, not what was proposed in some task (if those comments were outdated, and what this task proposes is the actual change, that’s a different matter of course).
Or are there Apple devices that support upto iOS 9 but not iOS 10?
Yes, iOS 10 dropped support for quite a few devices, see https://en.wikipedia.org/wiki/IOS_10#Supported_devices.
No. For Tech News, we care about humans, not browser versions. The only affected browsers with a measurable level of use which is subject to change is IE11 (0.098%) and Mobile Safari 6–9 (less than 0.002%). Chrome 13–20, Safari 5–9, and Opera 15–37 are all unmeasured (0), and so mentioning them would be disrespectful of the users who are actually affected, crowding out the real message with irrelevant side notes.
Apologies for derailing this task; discussion about announcing the change should really be on T333354.
The devices that can run iOS 9 but not 10 are the iPhone 4S, iPad 2, iPad (3rd generation), iPad Mini (1st generation) and iPod Touch (5th generation). None of these are usable devices for much of anything these days. Partly because iOS 9 received its last security update in 2016 (it also received a bug fix update as late as 2019 but that was completely out of cycle and due to unique circumstances) so connecting such a device to a public network is not recommended. Saying we are dropping support for devices that cannot run iOS 10 or later should be both clear and understandable. If necessary, tacking on "(like the iPhone 4S)" would give the relevant audience a reference point.
I didn’t say all browser versions should be mentioned. I said the entry shouldn’t say “you can upgrade to a newer version”, because not all people can update (in fact, probably most of the affected people can’t, as most of those who could have long done so).
Which doesn’t mean they aren’t used. Updating is often expensive (especially updating mobile devices, as that usually means throwing away the old device and buy a new one, but newer Windows versions also need to be bought), which people may not be able to afford.
I'm recording here the result of feature testing in older browsers, based on the demo page at https://people.wikimedia.org/~krinkle/T178356.html.
First off, a few easy ones via BrowserStack:
| Pass | Fail | |
|---|---|---|
| IE11 on Windows 7 | Status quo (DOM4, HTML5, ES5) | ES6 (all) |
| IE11 on Windows 10 | Status quo | ES6 (all) |
| Yandex Browser 14.12 (~2014, Chrome 38) | Status quo and ES6 Promise | ES6 Promise.finally, Array.includes, RegExp.flags, ArrowFn |
| Opera 76 (released June 2021) on Win 10 | Everything (Status quo, all ES6 checks) | – |
| Firefox 68 ESR (July 2019) on Win 10 | Everything | - |
| Chrome 79 (2019) on Win 8 | Everything | - |
| MSEdge 18 (May 2020, the last before Chromium-based Edge) on Win 10 | Status quo and ES6 Promise, Array, ArrowFn | ES6 RegExp.flags |
| Edge 80 (Jan 2020, first Chromium-based Edge) on Win 8 | Everything | - |
| Edge 80 (Jan 2020) on Win 10 | Everything | - |
| Firefox 48 (2016, last to support OS X 10.6) on OS X 10.6 Snow Leopard (released 2009) | - | Unable to connect with current TLS/HTTPS |
| Firefox 48 (2016, last to support OS X 10.8) on OS X 10.8 Mountain Lion (released 2012-2015) | - | Unable to connect with current TLS/HTTPS |
| Safari 7.1 on OS X 10.9 Mavericks (released 2013-2016) | - | Unable to connect with current TLS/HTTPS |
| Firefox 78 (2020, last to support OS X 10.9) on OS X 10.9 Mavericks (2013-2016) | Everything | - |
| Safari 8 on OS X 10.10 Yosemite (released 2014-2017) | - | Unable to connect with current TLS/HTTPS |
| Firefox 78 (2020, last to support OS X 10.10) on OS X 10.10 Yosemite (2014-2017) | Everything | - |
| Safari 9 on OS X 10.11 El Capitan (released 2015-2018) | - | Unable to connect with current TLS/HTTPS |
| Firefox 78 (2020, last to support OS X 10.11) on OS X 10.11 El Capitan (2015-2018) | Everything | - |
| Safari 10 on macOS 10.12 Sierra (released 2016-2019) | Status quo and ES6 Promise, Array, RegExp, ArrowFn | ES6 Promise.finally |
| Firefox 78 (2020) on macOS 10.12 Sierra (2016-2019) | Everything | - |
| Safari 11 on macOS 10.13 High Sierra (released 2017-2020) | Everything | - |
The rest are tested on a Samsung Galaxy S8 with Android 9.
| Pass | Fail | |
|---|---|---|
| Opera Mini (default) on Android 9 | Everything | - |
| Opera Mini (Extreme) on Android 9 | DOM4, ES5 | HTML5, ES6 (all) |
| UC Mini on Android 9 | Everything | - |
| UC Browser on Android 9 | Everything | - |
| UC Turbu on Android 9 | Everything | - |
Opera Mini on Android 9, uses the default "Normal" data saving mode. This is more or less just regular Opera/Chrome with some optimisations applied. It features the same Chrome and OPR branded User-Agent string as regular Opera returns.
Opera Mini on Android 9, using the "Extreme" data saving mode. This is classic Opera Mini, where the app functions as a proxy browser to a Presto browser engine running headlessly in the cloud. Note that what we refer to as "Opera Mini" (i.e. its Extreme mode) has already excluded from Grade A in MediaWiki since 2013. At the time through a User-Agent sniff, but as we find below this was became redundant a few years ago when we added localStorage to the list of checked features.
UC Mini is a bit of a mess. Apparently there are now three separate apps in the Google Play Store.
UC Mini by UCWeb. This one is advertised as "Download Video Status", which initially did not appear to be to the brand of a browser. It has 100M+ downloads according to the Play Store stats (I don't know over what period, and whether that's uniques or not, but I'll use it as a relative guide between the three to gauge their significance). UC Mini displays by default in the address bar that its "Premium Data Saving Mode" is "On". I could not find a way to turn this off, and assume this is its only mode. In a buried Settings panel, I did find a "Cloud Boost" option, which is enabled by default and I've left that on. The results pass all checks. It appears to be based on Chrome 57, although Chrome 57 itself would not have passed the same feature test so I'm guessing they've backported some things. Either way, it LGTM. The old user agent we sniffed against in startup.js is no longer used by the app now known as "UC Mini". UC Mini has a "Speed Mode" panel in its Toolbox modal, where you can opt-in to a "Lite" mode for a select number of websites including Google, Twitter and Yahoo. For "Others" the only option is "Mobile" or "Desktop". This suggests there is not a way to enable UC Mini Speed Mode for arbitrary websites, including not for Wikipedia.
UC Browser by UCWeb, advertised as "Safe, Fast, Private, download faster" with 1 bilion+ downloads according to Google Play Store, which currently offers version UC Browser version 13.4, last updated in October 2021. (Rather concerning for a browser to go for two years without updates. Or, they've dropped support for Android 9?) Despite being released in Oct 2021, it appears to be based on Chrome 78, which was released in Oct 2019. In any event, it passes all the checks in its default configuration. It too displays "Premium Data Saver Mode" as "ON' in its addres bar with no obvious impact of this does, nor can it be turned off. Its Settings panel too displays "Cloud Boost" which is on by default. The app features the same Speed Mode toolbox, and similarly not applicable to arbitrary websites or Wikipedia.
UC Turbo by UCWeb, advertised as "Fast, Safe, Ad Block" with 50M+ downloads according to Play Store stats, version 1.10, last updated in September 2021. Its user agent incudates tht it is like UC Mini in that it is based on the much older Chrome 57, although it has additional tokens for both UCBrowser and UCTurbo, and does in fact pass all proposed ES6 checks. Its settings reveal that "Powerful Ad Block mode" is enabled, as well as "Cloud acceleration" (no "Boost" this time, aye?). Independent research indicates that some or all of the UCWeb apps use cloud servers (e.g. HTTPS middle proxy) to track and/or optimise content and scripts. From what I can tell, it must do so independent of how the browser operates. That is, while it is likely proxying individual web request contents, this app is no longer what we refer to as a "proxy browser". From what I can tell, once the response to any given web request arrives, it gets rendered in-app like any other Chromium-based browser. I could not find any additional settings relating to a "Speed" or "Extreme" mode.
| UC Mini | UC Turbo | |
|---|---|---|
 |  |
Change 904389 had a related patch set uploaded (by Krinkle; author: Krinkle):
[mediawiki/core@master] es6-polyfills: Remove scripts, replace with deprecated stub
Change 902706 merged by jenkins-bot:
[mediawiki/core@master] ResourceLoader: Raise MW JavaScript startup requirement to ES6
Change 904389 merged by jenkins-bot:
[mediawiki/core@master] es6-polyfills: Remove scripts, replace with deprecated stub
Can we drop the web2017-polyfills as well? It looks like at least the URL ones are unneeded now from us dropping IE11...
The feature check in skip-web2017-polyfills.js for URL cuts at "Firefox 54, Safari 11, and Chrome 71".
The ES6 check in startup.js cuts at "Firefox 58+, Safari 11.1+, and Chrome 63+" (as of change 904851).
The leaves a gap in the form of Chrome releases from Dec 2017 to Jan 2019. Those are considered "Grade X" today, so we could cut them through an extra startup check, otherwise, they'll likely fall of the next time we raise the general level (~ in 1 year's time).
For now I'd say keep using web2017-polyfills in the knowledge that it safely no-ops and downloads no extra code for the majority of browsers.
Change 904851 had a related patch set uploaded (by Krinkle; author: Krinkle):
[mediawiki/core@master] ResourceLoader: Tweak startup.js known browsers explanation
Just noting because there were some user complaints on project:Support_desk, and it doesn't seem to be mentioned here explicitly - Firefox 52 is the last supported version on windows vista, which is no longer supported.