Gutenberg: Block-Editor: Missing DOMRect polyfill in 7.8 for IE11

[gwwar]

Testing Instructions

• Using WP 5.3.2/Gutenberg plugin 7.8 and IE11 in Windows, try interacting with the block toolbar:
• Several JS errors will fire
• Observe that window.DOMRect is undefined

Note that this should have been fixed by https://github.com/WordPress/gutenberg/pull/20110
but perhaps this is not being enqueued.

cc @aduth

[gwwar]

Is it intentional that we're missing the vendor folder in https://github.com/WordPress/gutenberg/releases/tag/v7.8.0 ?

[kwight]

@aduth Maybe https://github.com/WordPress/gutenberg/pull/20225/ has something to do with the vendor directory not being correctly assembled?

[aduth]

The vendor/ folder should be present. I'm not sure why it wasn't included in the release. When I run the plugin build script on master, I see that it fails and aborts at the step of downloading vendor scripts:

Downloading remote vendor scripts... 🛵


 > vendor/ ... %   

Dissecting the build, I see it runs this command:

https://github.com/WordPress/gutenberg/blob/27bfa8c70358fd4031e0f9bdb1379989f686caa8/bin/build-plugin-zip.sh#L77

Running that directly yields a more useful error:

⇒ php bin/get-vendor-scripts.php

Fatal error: Uncaught Error: Class 'WP_Patterns_Registry' not found in /Users/andrew/Documents/Code/gutenberg/lib/client-assets.php:654
Stack trace:
#0 /Users/andrew/Documents/Code/gutenberg/bin/get-vendor-scripts.php(33): require_once()
#1 {main}
  thrown in /Users/andrew/Documents/Code/gutenberg/lib/client-assets.php on line 654

For context, the vendor scripts are downloaded by loading the client-assets.php file with only a few WordPress functions stubbed (source). This code is problematic because it assumes these classes to already be defined, but they are not when the client-assets.php file is loaded directly:

https://github.com/WordPress/gutenberg/blob/27bfa8c70358fd4031e0f9bdb1379989f686caa8/lib/client-assets.php#L651-L659

These were introduced in #21074 (cc @youknowriad , @ellatrix )

Ideally, I think this code should be in its own file, and only executed in the context of an action callback, not run directly as part of the top-level PHP code.

As an immediate fix, it may be possible to simply add a class_exists guard to avoid that code being run in the plugin build script.

~My opinion is that this should be committed and cherry-picked to the release/7.8 branch for a plugin patch release.~ Noting below that this is technically not a regression of the current release version, though certainly a bug.

[aduth]

Fix: #21188

[aduth]

Noting that the vendor/ folder has been absent since 7.7.0 (2 major releases ago). You can see its removal here:

https://plugins.trac.wordpress.org/changeset/2258910

It was also the case that this specific DOMRect polyfill has been missing for some time (in fact, maybe never existed at all). This was technically fixed in #20225, but the current issue with WP_Patterns_Registry means the code implemented in that pull request is not currently able to run.

Also worth noting: This polyfill is provided with WordPress 5.4 (currently RC, scheduled for final release on Tuesday). Related: https://core.trac.wordpress.org/ticket/49360

---

Looking at this with @tellthemachines , I (we) am struggling to reproduce the exact issues reported, as far as errors or usability issues with the block toolbar.

I can confirm that the polyfill is missing (no DOMRect on the window). The full extent of the impact of this missing is not clear. I expect issues like #19979 may still be present.

---

21188 or an equivalent solution is still necessary, in order to allow the plugin code to run seamlessly.