Make WordPress Core

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#53078 closed defect (bug) (fixed)

Stop loading polyfills specific to Internet Explorer

Reported by: desrosj's profile desrosj Owned by: desrosj's profile 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:

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

Trac ticket:

#2 @desrosj
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 the window.fetch() function. This is present in all other supported browsers.
  • element-closest: polyfills Element.closest().
  • core-js-url-browser: polyfills the URL API.
  • objectFitPolyfill: polyfills support for the object-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 @youknowriad
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 @desrosj
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 @youknowriad
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.

#7 @youknowriad
4 years ago

Actually, it seems we do loop using for .. of

#8 @sergiomdgomes
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 @desrosj
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 @sergiomdgomes
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 @desrosj
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.

gziolo commented on PR #1209:


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 🎉

desrosj commented on PR #1209:


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.

#14 @gziolo
4 years ago

  • Keywords commit added

#15 @desrosj
4 years ago

  • Owner set to desrosj
  • Resolution set to fixed
  • Status changed from new to closed

In 50934:

Script Loader: Stop loading polyfills specific to Internet Explorer

This change removes the inline JavaScript attached to the wp-polyfill script responsible for loading polyfill libraries included specifically for Internet Explorer support.

Support for the final version of IE supported in WordPress Core (IE11) was removed in [50784] and will on longer be supported when the next version of WordPress is released.

These scripts are still registered and available to be enqueued, but WordPress will no longer load them by default.

For more information, see https://wordpress.org/news/2021/05/dropping-support-for-internet-explorer-11/.

Props youknowriad, gziolo, sergiomdgomes, desrosj.
Fixes #53078.

Note: See TracTickets for help on using tickets.