In T178356#8737546, @Tacsipacsi wrote:

In T178356#8736313, @Krinkle wrote:

This task is specifically about IE11 and iOS 9 only.

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).

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.

In T178356#8737546, @Tacsipacsi wrote:

In T178356#8736313, @Krinkle wrote:

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.

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.

In T178356#8737772, @Jdforrester-WMF wrote:

[…] mentioning them would be disrespectful of the users who are actually affected, crowding out the real message with irrelevant side notes.

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).

In T178356#8737882, @Xover wrote:

None of these are usable devices for much of anything these days.

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:

• https://www.mozilla.org/en-US/firefox/78.0/releasenotes/
• https://www.mozilla.org/en-US/firefox/48.0/releasenotes/

The rest are tested on a Samsung Galaxy S8 with Android 9.

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

https://gerrit.wikimedia.org/r/904389

Change 902706 merged by jenkins-bot:

[mediawiki/core@master] ResourceLoader: Raise MW JavaScript startup requirement to ES6

https://gerrit.wikimedia.org/r/902706

Change 904389 merged by jenkins-bot:

[mediawiki/core@master] es6-polyfills: Remove scripts, replace with deprecated stub

https://gerrit.wikimedia.org/r/904389

Can we drop the web2017-polyfills as well? It looks like at least the URL ones are unneeded now from us dropping IE11...

In T178356#8745921, @DLynch wrote:

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

https://gerrit.wikimedia.org/r/904851

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.

After the updates on April 6, 2023, most of the JavaScript-based functions required to work in the Wikipedia project stopped working.
Operating system Windows XP Professional Service Pack 3.
Browser Google Chrome 49.0.2623.112.
Please, bring back Java Script support for older browsers.

@Jim_Hokins: No, see reasons above. Please upgrade your insecure old browsers instead.

Windows XP has been unsupported for 9 years, Chrome 49 for 7 years. JavaScript engines are infamous for containing tons of security bugs, so it is your own best interest not to use JavaScript either on Wikimedia sites or on any other sites (go to chrome://settings/content to entirely disable JS in Chrome). And of course to upgrade to a supported operating system and browser ASAP (Windows 10/11 being the most natural choice, but you may try Lubuntu (64-bit only) or Debian (both 32-bit and 64-bit, but requires a bit more setup) if you’re tight on resources – which is probably the case if you’re still using XP).

Ребята, мне не нужны советы вида "Обновите браузер/обновите операционную систему/обновите оборудование". Я тупо хочу продолжать редактировать Википедию, ничего не меняя. Если вы не хотите, чтобы я редактировла Википедию, то скажите об этом прямо. Мне не трудно будет перестать этим заниматься.

And we don’t need people crying and protesting when we say them that their systems are insanely outdated. You don’t have to upgrade. You don’t even have to upgrade to continue to be able to edit Wikipedia. But you have to accept that the web went on and some extra features no longer work on insanely outdated systems. Supporting these systems takes extra time for developers. Extra time that could be spent on fixing bugs or developing new features. It also means a lot of extra code that every user, and not just those who cling to use these ancient browsers, need to download, causing extra bandwidth usage and download time. Bandwidth usage that could be spent on downloading more articles and time that could be spent on actually reading the articles instead of just waiting for them to load.

Tacsipacsi, сынок, я не плачусь, ты попутал. Плачешься ты. А я просто ухожу. Успехов.

Note: Windows XP with IE or Chrome has not been able to connect to Wikipedia to read (much less, utilize JavaScript) for several years due to newer TLS ciphers required by our HTTPS stack.

Firefox 52 ESR however will continue to be available on Windows XP for a basic experience. The basic experience includes search, login, and most importantly: Editing (albeit through wikitext rather than the visual editor). Nothing about this task is removing the ability to edit for any browser, in accordance with our robust frontend strategy and compatibility guidelines.

Refer to https://wikitech.wikimedia.org/wiki/HTTPS/Browser_Recommendations for instructions on what browsers are recommended on older operating systems.

In T178356#8766548, @Krinkle wrote:

Note: Windows XP with IE or Chrome has not been able to connect to Wikipedia to read (much less, utilize JavaScript) for several years due to newer TLS ciphers required by our HTTPS stack.

Actually, I just tried Chrome 49 on a Windows XP SP3 virtual machine, and Wikipedia loaded fine. IE6 indeed didn’t load any HTTPS site (not even Wikitech).

Recording here, so this is not lost - this fixed quite a few JS errors in our code:

• SyntaxError: Block-scoped declarations (let, const, function, class) not yet supported outside strict mode - there were 7,655 instances of this error in wmf2, 0 so far in wmf3

{F36946069}

• All SyntaxErrors

104,726 instances of this error in wmf2, and only 17,685 so far in wmf3

In T178356#8768594, @Jdlrobson wrote:

{F36946069}

This image is not visible, could you please attach to the task? Thanks in advance!

xs

What does this mean?

I assume it is this change which has removed a swathe of functionality for users of Puffin Browser, a remote browser. Until now this has been a great choice for speed and UI on iPad. However, now I have lost editing toolbar (formatting, cite and advanced tools), Wiki markup beneath the editing window, collapsed sections of pages, XFDCloser, triangles to look in subcats on category pages...

This adds up to a significant hindrance to me as one of the lead admins on enwiki Categories for Discussion.

@Fayenatic_london: I'd recommend to contact Puffin developers to improve support for ECMAScript 2015 (ES6) in Puffin Browser.
Please refer to https://wikitech.wikimedia.org/wiki/HTTPS/Browser_Recommendations for instructions on what browsers are recommended on certain systems.

@Aklapper note that it is not just ES6 what we require. We dropped ES5 browsers and made ES6 a requirement, but there are additional requirements !

We target ES6 + Promise finally (ES 2018, but was implemented pretty early by most browsers) + Array includes (ES 2016, but present in most ES6 browsers) + Arrow function support + Regexp flags support.

This is clear in iOS Safari 10 vs iOS Safari 11 support. While 10 does implement ES6, and even ES 2016 in 10.1, it doesn't have 2018 promise finally (which arrived in 11.3). The last version of Safari 10 was made in 2016, and the last release of Safari 11 was in 2018. So while we do not require full ES2017/2018 support, we do require some parts of it.

@Krinkle I'm looking at the numbers and I'm wondering if maybe we made a mistake in the analysis? I notice that everywhere we indicate that promise.finally is ES6, but Promise.finally is ES2018. The feature check was gating the promise polyfill because the polyfill was implementing es6 AND es2018 features. This also reflects why originally we were stating Safari 10 instead of Safari 11.

I doubt the usage numbers are very significant, but perhaps we should double check if we should move the promise polyfill back in ? It could be more users than all of IE11.....

Note that all browsers on iOS use WebKit engine (Chrome, Opera and even Firefox). So I doubt Puffin Browser can do anything about what they support. This is due to Apple policy which bans browser engines on their store. I guess most devs know that, but every browser on iOS is a skin over Safari (mostly).

So if you require Safari 11 then iPhones/iPads roughly from <del>2017</del> 2014 should be fine (and older then that won't get JS).
In contrast Android version 4.4 received browser updates last time I checked so Android devices from about October 2013 should be fine (at least with Chrome and possibly Firefox). Don't have Android 4.4 handy to confirm, but VE works fine on Android 5.0 in Chrome 75. FF 111 also works on Android 5.0.

Note that all browsers on iOS use WebKit engine (Chrome, Opera and even Firefox). So I doubt Puffin Browser can do anything about what they support. This is due to Apple policy which bans browser engines on their store. I guess most devs know that, but every browser on iOS is a skin over Safari (mostly).

Puffin browser allegedly gets arround that by streaming a video of chromium running somewhere in the cloud.

Firefox 68 ESR was the last version to support Android 4.4. So KitKat users still get JS, but their Firefox is no longer graded A (which means the last two ESR versions on Android as well, even though 68 was AFAIK the only version that was really released as ESR on Android?).

This is the current status of JavaScript feature support beyond ES5 in mainstream browsers passing current check:

• ES2016 (ES7): all supported
• ES2017 (ES8): all supported
• ES2018 (ES9): Lookbehind in JS regular expressions - require Safari 16.4 and Firefox 78; RegExp.prototype.dotAll - require Firefox 78; named capture groups - require Firefox 78; Unicode property escapes - requires Firefox 78
• ES2019 (ES10): current version of Safari does not support Function.prototype.toString revision; other than this, the minimum version supporting all feature is Firefox 64+, Safari 12.1+, Chrome 73+, Opera60+, Edge 79+

Conclusion: We can now use all JavaScript features up to ES2017, plus non-regex features in ES2018.

I propose the next step after this task is to remove JavaScript from browser without globalThis support (which is one of ES2020 features, but supports somewhat earlier in browsers).

Currently https://phabricator.wikimedia.org/source/mediawiki/browse/master/resources/src/startup/startup.js contains more than 10 lines (and more than 30 if comments are counted) inside isCompatible and this doing so will simplify the entire check to one line: 'globalThis' in window.

Currently the check in startup.js cuts at: Firefox 58+, Safari 11.1+, Chrome 63+, Opera 50+, Edge 79+; 95.63% (95.65% - 0.02% of Edge 18) usage

And the proposed check will cut at: Firefox 65+, Safari 12.2+, Chrome 71+, Opera 58+, Edge 79+; 94.32% usage

For comparison this is some of minimum versions for ES2016-ES2020 features mentioned at T277675: Add native support for ES2016-ES2020 or higher versions:

The following features should be fully supported in mainstream browsers passing current check:

• (ES2016) ** operator - Firefox 52+, Safari 10.3+, Chrome 52+, Opera 39+, Edge 14+
• (ES2017) Object.values - Firefox 47+, Safari 10.1+, Chrome 54+, Opera 41+, Edge 14+
• (ES2017) async functions - Firefox 52+, Safari 11+, Chrome 55+, Opera 42+, Edge 15+
• (ES2017) padStart - Firefox 48+, Safari 10+, Chrome 57+, Opera 44+, Edge 15+
• (ES2018) for await - Firefox 58+, Safari 11.1+, Chrome 63+, Opera 50+, Edge 18+
• (ES2018) spread (...) syntax - Firefox 16+, Safari 8+, Chrome 46+, Opera 37+, Edge 12+
• (ES2019) optional catch binding - Firefox 58+, Safari 11.1+, Chrome 63+, Opera 50+, Edge 18+

The following requires a higher threshold (though lower than proposed in this task):

• (ES2019) trimStart - Firefox 58+, Safari 11.1+, Chrome 66+, Opera 53+, Edge 79+ (the only gap is Chrome 63-65 and Opera 50-52)
• (ES2019) flatMap - Firefox 62+, Safari 12+, Chrome 69+, Opera 56+, Edge 79+
• (ES2020) import.meta - Firefox 62+, Safari 11.1+, Chrome 64+, Opera 51+, Edge 79+ (the only gap is Chrome 63, Opera 50 and Firefox 58-61)

The following requires a higher threshold than proposed in this task:

• (ES2019) Object.fromEntries - Firefox 63+, Safari 12.1+, Chrome 73+, Opera 60+, Edge 79+
• (ES2020) ?? and ?. operators, dynamic import (requires Firefox 67), export * as Foo from 'bar', BigInt (requires Safari 14), matchAll(), Promise.allSettled()

In T178356#8782595, @Bugreporter wrote:

Conclusion: We can now use all JavaScript features up to ES2017, plus non-regex features in ES2018.

Note: as of now, the minifier supports only upto ES2016. So using async functions and the like will have to wait for minifier upgrades. T277675 is the task to track that I believe.

Change 904851 merged by jenkins-bot:

[mediawiki/core@master] ResourceLoader: Tweak startup.js known browsers explanation

https://gerrit.wikimedia.org/r/904851

Change 913663 had a related patch set uploaded (by Krinkle; author: Krinkle):

[mediawiki/core@master] ResourceLoader: Fix startup.js comment, Promise.finally is ES2018

https://gerrit.wikimedia.org/r/913663

In T178356#8774962, @TheDJ wrote:

@Krinkle I'm looking at the numbers and I'm wondering if maybe we made a mistake in the analysis? I notice that everywhere we indicate that promise.finally is ES6, but Promise.finally is ES2018.

Good catch. I've fixed the startup.js comment in https://gerrit.wikimedia.org/r/913663.

I doubt the usage numbers are very significant, but perhaps we should double check if we should move the promise polyfill back in? It could be more users than all of IE11.....

As I understand it, our current Compatibility policy doesn't cover Safari 10 either way. The policy is always a subset of the wider range of Grade X browsers that technically pass the feature test. E.g. there are about 3 years of Firefox releases that we don't "support" but do meet all present day technical requirements and so continue to recieve the full experience today the same way we also provide it to lesser known browser families that meet the requirements (per T102318: Convert startup blacklist to feature test).

Regarding other ES2018 features, there is a notable gap between ratifying a specification and the last major browser shipping an implementation. Some features ship in all browsers ahead of the spec finalising, others take decades to ship or get cancelled after some time (e.g. some ES2015/ES6 features still haven't shipped). Hence the fact that we guruantee presence of one ES2018-based API is not reason to bump the general grammar and runtime requirement to ES2018 or to guruantee other <= ES2018 features.

Change 913663 merged by jenkins-bot:

[mediawiki/core@master] ResourceLoader: Fix startup.js comment, Promise.finally is ES2018

https://gerrit.wikimedia.org/r/913663

As a note, for users still running Windows XP they may install an unofficial derived browser based on Chromium, such as https://en.wikipedia.org/wiki/360_Secure_Browser which (as of version 13) is based on Chromium 86.

(ES2018) for await - Firefox 58+, Safari 11.1+, Chrome 63+, Opera 50+, Edge 18+

For the record: This is incorrect. Both async and await comes with ES2017/ES8. See e.g.: https://flaviocopes.com/es2017/#async-functions and also https://262.ecma-international.org/8.0/

Browser support: https://caniuse.com/?search=await
Firefox 52+ does support async/await: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/52

I noticed MW core doesn't support Windows XP now, but async/await would work. To be clear, I'm kind of glad sites stopped supporting Windows XP ;-), but just wanted to get the facts straight.

(ES2018) spread (...) syntax - Firefox 16+, Safari 8+, Chrome 46+, Opera 37+, Edge 12+

This is also incorrect. Both spread and destructive assignment is part of ES6/ES2015:
https://compat-table.github.io/compat-table/es6/

In T178356#9458355, @Nux wrote:

(ES2018) for await - Firefox 58+, Safari 11.1+, Chrome 63+, Opera 50+, Edge 18+

For the record: This is incorrect. Both async and await comes with ES2017/ES8. See e.g.: https://flaviocopes.com/es2017/#async-functions and also https://262.ecma-international.org/8.0/

It's not incorrect. for await is for asynchronous iteration which appeared only in ES2018. https://caniuse.com/?search=for%20await

In T178356#9458411, @SD0001 wrote:

In T178356#9458355, @Nux wrote:

(ES2018) for await - Firefox 58+, Safari 11.1+, Chrome 63+, Opera 50+, Edge 18+

For the record: This is incorrect. Both async and await comes with ES2017/ES8. See e.g.: https://flaviocopes.com/es2017/#async-functions and also https://262.ecma-international.org/8.0/

It's not incorrect. for await is for asynchronous iteration which appeared only in ES2018. https://caniuse.com/?search=for%20await

Oh, sorry. I thought that was "for await" as in "as for await" ;)

So I guess this:

(ES2018) spread (...) syntax - Firefox 16+, Safari 8+, Chrome 46+, Opera 37+, Edge 12+

Might mean not spread in general, but spread in objects like this one:

let { x, y, ...z } = { x: 1, y: 2, a: 3, b: 4 };
x; // 1
y; // 2
z; // { a: 3, b: 4 }

https://github.com/tc39/proposal-object-rest-spread

But spread in objects is not supported in FF52:
https://web.archive.org/web/20180721150407/http://kangax.github.io/compat-table/es2016plus/

So that info about spread is still somewhat inaccurate.