Drop support for Edge Legacy (EdgeHTML-based) in 4.0?

[mgol]

Description

We've touch the topic a few time but I thought it'd be good to have any decision we make publicly available on GitHub.

Our browser support policy states we support "(Current - 1) and Current" versions of Edge. Right now it's Edge with EdgeHTML 17 & 18^[1] but the new Chromium-based Edge version (v79^[2]) is slated for a public release on January 15, 2020. Version 80 should follow a few weeks afterwards as they'd be following the Chromium release calendar. Technically speaking, that means jQuery will officially no longer support the legacy EdgeHTML-based Edge versions (as the two latest versions will be 79 & 80, both Chromium-based). However, I feel an engine switch is a big enough event that we should make any decisions about dropping support - even if technically we don't have to - more consciously. Therefore, I wanted to explain how I see the Edge situation after January 15, 2020.

The public release of the new Edge will probably not mean auto-updating everyone on Windows 10 to it but I expect the next Windows 10 "feature update" (which should be released around April/May 2020) will include it.

Microsoft still supports EdgeHTML 16, 17 & 18 on Enterprise & Education versions of Windows 10 so those OS lines may take a bit more to update (installing the Chromium-based Edge is supported in all of them, though). Microsoft will also still support EdgeHTML-based WebView in addition to the new Chromium-based one; there's no timeline to remove the old WebView. Some platforms, like Windows 10 on ARM or Xbox will not get the new Edge at the same time as most desktop Windows versions will.

Dropping EdgeHTML supports would bring us some advantages: it'd decrease the minified gzipped jQuery size by 230 bytes as of now and it'd allow us to restrict some workarounds needed by IE & Edge to just IE by a documentMode check. That fits nicely with other legacy workarounds removals in 4.0, making jQuery faster especially for modern browsers.

I'd keep testing jQuery 3.x with at least EdgeHTML 18 even though technically it will fall out of our supported browsers list soon.

[1]: For support purposes we use EdgeHTML versions rather than Edge app versions which are now at v44
[2]: Chromium-based Edge aligns its major version with Chromium, getting rid of current two separate versioning strategies for the app & its web engine

Link to test case

N/A

[mgol]

I created a draft PR so that it's easier to see what kind of changes we could introduce if we dropped EdgeHTML: #4573.

[mgol]

@kytosai This issue is not about removing support for Edge (which we have no plans to do) but for EdgeHTML, i.e. the engine powering the legacy Edge versions that will be replaced by Chromium on January 15, 2020.

IE 11 support cannot be removed yet as:

1. It is still the default browser in Windows 7 & 8.1.
2. It is still included in Windows 10 & that won't change after the new Edge gets released.
3. Due to its ActiveX support as well as IE dominance history there are still many environments that depend on IE 11 support. That's not the case for EdgeHTML. It's not only corporate environments! See e.g. South Korea stats for last month: https://gs.statcounter.com/browser-version-partially-combined-market-share/desktop/south-korea/#monthly-201911-201911-bar. While IE 11 usage is getting lower, it's still at 17.45%! That's enormous. Compare that with Edge 18's 4.36% and take into account that will most likely decrease significantly as soon as the new Edge gets released.

Maybe we'll be able to drop IE support in a few years, if jQuery still exists by then. But that's too far a future to seriously consider it at the moment.

[mgol]

Paging people who might be interested in voicing their opinion here: @jquery/core @Krinkle @arschmitz @fnagel

[Krinkle]

This may be of interest as well: analytics.wikimedia.org/dashboards/browsers

Illustrated: Desktop traffic to Wikipedia and sister projects, by browser family and major version. From 15-22 Dec 2019. IE 11 makes up 8.1% globally, Edge 18 makes up 4.1% globally.

In context: stats.wikimedia.org says the desktop sites receive around 10B page views a month. The English Wikipedia specifically, receives 5B of those 10B desktop page views, from an estimated 260M desktop-device sessions.

[Krinkle]

@mgol For Wikipedia, dropping legacy Edge for client-side enhancements (Grade A) would likely be fine if our traffic shows it being <1% of desktop globally.

We generally support individual browsers if they are used by at least 1% of readers globally. And our current Grade A matrix is generally a superset of these >=1% browsers (additional browsers added or removed based on consensus and available resources).

[fnagel]

I never really tested my projects with Edge and no client ever asked for it but ~4% (almost 5 in some stats) worldwide usage is enough for me to say: let's keep it in the 4.0 release.

How much speed to we gain by removing?
What else do we plan to remove in the 4.0 release?

I'd keep testing jQuery 3.x with at least EdgeHTML 18 even though technically it will fall out of our supported browsers list soon.

+1

[mgol]

@fnagel

~4% (almost 5 in some stats) worldwide usage is enough for me to say: let's keep it in the 4.0 release

~4% is the current statistic. I suspect it will go down a lot once the Chromium-based Edge is released on January 15 as Microsoft is aiming at a pretty aggressive update schedule, even updating older Edge versions on older Windows 10 feature updates. And jQuery 4.0.0 will not get released soon, I think 6 months into the future is an optimistic estimate.

If we want to know for sure how the update goes, we can wait a month or two and see if usage of EdgeHTML-based versions of Edge drops significantly during that time or not.

How much speed to we gain by removing?

I described that in my original post. Do you have an additional question to what I wrote there?

What else do we plan to remove in the 4.0 release?

Nothing that we haven't removed already (though we can always decide to restrict that further if we think it makes sense). See #4299 & #3950. Also, I submitted a draft PR to update the jQuery browser support page at jquery/jquery.com#194 so you can have a look at our current plans.

[fnagel]

Thanks for your fast reply!

If we want to know for sure how the update goes, we can wait a month or two and see if usage of EdgeHTML-based versions of Edge drops significantly during that time or not.

You're right. Those numbers will most likely drop the next few month but how much? MS pushes those updates more aggressively but as their ecosystem does not adapt, lots of people and companies block updates (at least those feature updates).
Anyway, waiting a little longer to have better figures as base for a decision sounds like a good plan!

How much speed to we gain by removing?

I described that in my original post. Do you have an additional question to what I wrote there?

I only found this sentence regarding speed gains "That fits nicely with other legacy workarounds removals in 4.0, making jQuery faster especially for modern browsers.".

Nothing that we haven't removed already (though we can always decide to restrict that further if we think it makes sense). See #4299 & #3950.

Thanks. Looking at those IE usage numbers (e.g. global IE 10 usage at 0.15% and IE 9 at 0.36%) I feel confirmed saying that Edge 18 should be supported a little longer (conditional how the usage numbers will change the next few month).

[mgol]

I only found this sentence regarding speed gains "That fits nicely with other legacy workarounds removals in 4.0, making jQuery faster especially for modern browsers.".

Have a look at my draft PR removing EdgeHTML support: #4573. Some improvements:

1. Look at removals containing support. and also at the test in src/selector/rbuggyQSA.js - these are support tests that we have to run right now as the bug exists in EdgeHTML as well; if we dropp it, we can just use the isIE check, saving on a support test run which slightly improves performance, especially the first time a particular API runs (it also improves final jQuery size).
2. In one place in src/selector.js we had to apply an unload handler for IE & Edge but a support test was impossible so we did it for all browsers; if we drop EdgeHTML, we can check for isIE and only attach the handler in IE.

These are not extreme performance gains but it fits into our significant performance improvements in the selector module for jQuery 4.0 that were possible mainly by dropping lots of workarounds & support tests for legacy browsers.

[mgol]

Also, note that some of the support tests removed in that PR are quite new; as people encounter more issues in IE that still exist in EdgeHTML, there's a potential of having more & more of them in the code.

[arschmitz]

I personally would say its not possible to decide this right this second the current usage is much to high to drop and while i hope with the January and subsequent releases of edge that it will drop low enough that its fine to drop. No one can really say that right now.

[Krinkle]

I would expect this update to not be blocked by companies differently than other Edge updates.
It looks like usage has generally shifted quite quickly for EdgeHTML releases, e.g. from Edge 15 ->16 -> 17 -> 18 etc. From what I can tell, Microsoft will release this as a normal update (not as a major/special release). This is in part because while Edge is changing their engine to Chromium/Blink, they also continue to bundle the various compat modes for legacy sites.

But yeah, we'll have to wait and see :)

[mgol]

while Edge is changing their engine to Chromium/Blink, they also continue to bundle the various compat modes for legacy sites

@Krinkle What do you mean by that? The only thing I know about is IE mode which is essentially running a page with an IE 11 engine for sites on a special group policy list.

It looks like usage has generally shifted quite quickly for EdgeHTML releases, e.g. from Edge 15 ->16 -> 17 -> 18 etc.

Also, note that for these upgrades a Windows 10 feature update was required which could be blocked by some companies for reasons other than not wanting a newer browser. The Chromium-based Edge will be delivered independently of Windows 10 feature updates so I expect fewer reasons to block.

[timmywil]

Moved to the ROADMAP. We will keep an eye on the market share and drop EdgeHTML when we can.

[mgol]

Newest info:

After March 9, 2021, the Microsoft Edge Legacy desktop app will not receive new security updates.

https://techcommunity.microsoft.com/t5/microsoft-365-blog/microsoft-365-apps-say-farewell-to-internet-explorer-11-and/ba-p/1591666

[mgol]

I'd like to reopen the discussion. I analyzed recent market share data and here are my conclusions:

1. In the past few weeks here's how Edge Legacy (all versions: 12-18) market share within desktop browsers looks like^[1]; it's going down quickly and it's already way below 1%.:
   • last 4 weeks: 1.04%
   • last 3 weeks: 0.97%
   • last 2 weeks: 0.91%
   • last 1 week: 0.88%
2. If we check just Edge 18 (the only version we still officially support) and look at the overall market share in the past 4 weeks, without singling out just desktop browsers then the share is only 0.38%.
3. Wikimedia data that @Krinkle linked above shows the following stats for Edge Legacy:
   • last 4 weeks: 1.05%
   • last 3 weeks: 1.01%
   • last 2 weeks: 0.95%
   • last 1 week: 0.90%

Based on the above data & the fact that any support for Edge Legacy from Microsoft, including security fixes ends on March 9, 2021, I think we should drop support for that browser in jQuery 4.0.

[1] I'm looking at weeks since usually the share is different during weekends so full weeks are less volatile than days or months.

[mgol]

PR: #4792