[wp-trac] [WordPress Trac] #49360: Scripts: Add polyfill for window.URL
WordPress Trac
noreply at wordpress.org
Tue Feb 11 20:42:56 UTC 2020
#49360: Scripts: Add polyfill for window.URL
---------------------------+-------------------------
Reporter: aduth | Owner: aduth
Type: enhancement | Status: reopened
Priority: normal | Milestone: 5.4
Component: Script Loader | Version: trunk
Severity: normal | Resolution:
Keywords: has-patch | Focuses: javascript
---------------------------+-------------------------
Changes (by aduth):
* status: closed => reopened
* resolution: fixed =>
Comment:
I recently discovered that the URL polyfill from the `polyfill-library`
library is not spec-conformant, in a way which negatively impacts its
usability for pending revisions to the block editor. Specifically, there
were revisions to the implementation of the `wp-url` script to detect URL
validity by relying on thrown errors from the URL constructor, but this
specific behavior is not implemented in this version of the polyfill.
More information:
- https://github.com/Financial-Times/polyfill-library/issues/462
- https://github.com/WordPress/gutenberg/pull/19871
- https://github.com/WordPress/gutenberg/pull/20172#issuecomment-584781181
The impact of this is that usage of `wp.url.isURL` will return `true` for
invalid URLs in browsers where the polyfill is used. Specifically, this
affects a few behaviors such as:
- Selecting a URL text in a paragraph and clicking "Add Link" would
normally prepopulate that URL.
- Pasting a URL from an oEmbed source into an empty paragraph will
normally insert an Embed block automatically.
These will not work correctly in Internet Explorer using the polyfill
committed in r47238.
On my assessment, none of these behaviors are critical, but an alternative
polyfill should be explored.
The following alternative implementations have been confirmed to have
correct error throwing behavior:
- [https://github.com/jsdom/whatwg-url jsdom/whatwg-url]
- [https://github.com/zloirock/core-js/ core-js]
However, unlike our existing polyfills, neither of these come pre-packaged
as a browser-ready distributable.
The following options may be viable:
- Use a package which re-distributes one of the above as a browser-ready
bundle (e.g. [https://github.com/stevenvachon/universal-url universal-
url], [https://www.npmjs.com/package/core-js-bundle core-js-bundle])
- Since sourcing/copying the polyfills already occurs as
[https://github.com/WordPress/wordpress-
develop/blob/c83253c7f82cd87e1212a48946238638b99dd68d/tools/webpack/packages.js#L74-L95
part of the Webpack build], the build configuration could be adapted to
generate the browser-ready bundles on-demand. This would be a slightly
larger task, considering that the current implementation of vendor scripts
build only supports basic file copying.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/49360#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list