#53078 closed defect (bug) (fixed)
Stop loading polyfills specific to Internet Explorer
Reported by: | desrosj | Owned by: | desrosj |
---|---|---|---|
Milestone: | 5.8 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Script Loader | Keywords: | has-patch commit |
Focuses: | Cc: |
Description
There are several polyfills included in Core that are loaded specifically for supporting Internet Explorer.
Now that IE11 support has been dropped, these polyfills are no longer necessary.
This ticket is for discussing when Core should stop loading them.
Regardless of when Core stops enqueuing them, they will need to remain in Core in case plugins and themes are declaring them as dependencies for their own scripts.
For context, see:
- https://make.wordpress.org/core/2021/03/04/discussion-dropping-support-for-ie11/
- https://make.wordpress.org/core/2021/03/25/discussion-summary-dropping-support-for-ie11/
- https://make.wordpress.org/core/2021/04/22/ie-11-support-phase-out-plan/
Related: #53077.
Change History (16)
This ticket was mentioned in PR #1209 on WordPress/wordpress-develop by desrosj.
4 years ago
#1
- Keywords has-patch added
#2
@
4 years ago
- Component changed from General to Script Loader
After some investigating, it looks like the following dependencies are polyfills specifically for IE11 only:
whatwg-fetch
: polyfills thewindow.fetch()
function. This is present in all other supported browsers.element-closest
: polyfillsElement.closest()
.core-js-url-browser
: polyfills the URL API.objectFitPolyfill
: polyfills support for theobject-fit
CSS property.
The polyfill-library
is responsible for 2 IE11 specific polyfills in Core:
- One that polyfills the Node.contains() function.
- One that backports the DOMRect API.
The last one, formdata-polyfill
, polyfills elements of the FormData API for consistent experience across browsers. It does look like some aspects are relevant for browsers other than IE. For example, for...of
support is added in Edge, set()
support in Opera, and it makes the API available in workers for Safari.
Some other details to consider. These scripts are only loaded if they are actually needed. And the polyfills need to continue to be bundled in Core just in case a plugin or theme is specifying as a dependency or enqueueing. So it may be worth not making the changes in the PR. But, IE11 was removed from the Gutenberg repository, so that may not even matter anymore.
This ticket was mentioned in Slack in #core-editor by desrosj. View the logs.
4 years ago
#4
@
4 years ago
Thanks for auditing these
Some other details to consider. These scripts are only loaded if they are actually needed. And the polyfills need to continue to be bundled in Core just in case a plugin or theme is specifying as a dependency or enqueueing.
IMO, we shouldn't keep these poly fills around, but we just keep the WP script handle (with an empty content), that way, plugins referring to these handles won't break but IE11 support is removed.
These discrete poly fills are needed for IE11 only so should be good to go. The most complex one we'd have to deal with is wp-polyfill
which corresponds to the now deprecated babel-polyfill
. this contains a number of generic JS polyfills like generator runtime, Map, Set, some new array functions... While most of these are only required for IE11, some of these might be required for the currently supported browers. And this polyfill is a dependency of all scripts and it's the biggest one, so I believe we need to do some work here in order to know what exactly is needed for IE11 only and can be safely removed. We can use core-js
to build a custom light version of this polyfill. I expect that we'll see a very big drop in terms of Kbs shipped in the end.
#5
@
4 years ago
@youknowriad can you confirm that formdata-polyfill
is not needed for those edge cases in other browsers?
For wp-polyfill
, I think we leave that one be and address it in #52941.
#6
@
4 years ago
I confirm that we don't need these edge cases. We only use it for meta boxes compatibility. And it seems we only use the contructor, append function and we pass it as argument to window.fetch
.
#8
@
4 years ago
The for...of
portion of formdata-polyfill
is only necessary for really old Edge versions, pre-18. This means that even the last "old Edge" versions should support it, and new Edge is not a problem at all, since it's Chromium-based.
Do we need to support Edge < 18? If not, we should be able to drop formdata-polyfill
entirely: https://developer.mozilla.org/en-US/docs/Web/API/FormData#browser_compatibility
#9
@
4 years ago
Thanks @sergiomdgomes!
When I originally investigating, I referenced the native browser compatibility section in the polyfill's Readme file. This indicates that no versions Edge support for...of
.
However, I just did some more digging and it seems that this is incorrect according to Can I use.
With this in mind, I think that we can also stop loading the formdata-polyfill
. I'll update the PR.
#10
@
4 years ago
Ah yes, that explains it! It does look like the polyfill's page is incorrect, or at least outdated. Thank you, @desrosj! 👍
#11
@
4 years ago
Was revisiting this today and realized the current approach in my PR will not work.
The scripts would no longer be registered with that approach. The scripts should continue to be available for plugins and themes to enqueue if their code requires these polyfills. This is important because if anyone is currently defining these as dependencies for their custom code, that code would stop loading on update.
I'm leaning towards two options:
- Remove the inline script attached to
wp-polyfill
in 5.8. This would stop the polyfills from loading but would allow someone else to enqueue or load them. - Wait and remove these other polyfills until
wp-polyfill
is evaluated in #52941.
4 years ago
#12
https://developer.mozilla.org/en-US/docs/Web/API/URL_API
There is a remark for URL
and Safari
In Safari 14 and earlier, calling the URL constructor with a base URL whose value is undefined causes Safari to throw a TypeError; see WebKit bug 216841.
Otherwise according to MDN Web Docs all polyfills are no longer necessary 🎉
4 years ago
#13
@gziolo I think this is an acceptable edge case. I'm also not sure that the polyfill would fix this issue. The URL()
API exists on those versions of Safari, so it's possible that the polyfill is not even used for those versions of Safari.
#15
@
4 years ago
- Owner set to desrosj
- Resolution set to fixed
- Status changed from new to closed
In 50934:
4 years ago
#16
Merged into Core in https://core.trac.wordpress.org/changeset/50934.
Trac ticket: