@swissspidy: I'd love your eyes on this, if you can spare some time today (edit: not urgent as initially thought).

The fix for 8.7 needs to be applied to lib/blocks.php. Unit tests probably will continue work without change.

(Code was moved and files renamed by #24351)

Size Change: +381 B (0%)

Total Size: 1.16 MB

_{compressed-size-action}

OK, so this is not affecting WP 5.5 (feel free to double-check), which makes sense considering that the functionality in question (Global Styles-related block support) was intentionally merged after code freeze.

I'll update the metadata accordingly.

I've also tested and confirmed that this does not appear to affect WordPRess 5.5.

FAIL packages/e2e-tests/specs/editor/various/adding-blocks.test.js (26.685s)
  ● adding blocks › inserts a block in proper place after having clicked `Browse All` from inline inserter

    expect(received).toMatchSnapshot()

    Snapshot name: `adding blocks inserts a block in proper place after having clicked \`Browse All\` from inline inserter 2`

    - Snapshot  - 4
    + Received  + 0

    @@ -1,13 +1,9 @@
      <!-- wp:paragraph -->
      <p>First paragraph</p>
      <!-- /wp:paragraph -->

    - <!-- wp:cover -->
    - <div class="wp-block-cover has-background-dim"><div class="wp-block-cover__inner-container"></div></div>
    - <!-- /wp:cover -->
    -
      <!-- wp:heading -->
      <h2>Heading</h2>
      <!-- /wp:heading -->

      <!-- wp:paragraph -->

      259 | 		);
      260 | 		await coverBlock.click();
    > 261 | 		expect( await getEditedPostContent() ).toMatchSnapshot();
          | 		                                       ^
      262 | 	} );
      263 | } );
      264 | 

      at Object.<anonymous> (specs/editor/various/adding-blocks.test.js:261:42)
          at runMicrotasks (<anonymous>)

 › 1 snapshot failed.

😕

Seems like the DOM operation might remove the empty Cover div? 🤔

Seems to pass locally. I'll re-run the test.

Passing now 😌

We should add some test coverage for this though 🤔

We should add some test coverage for this though 🤔

A simple unit test for gutenberg_apply_block_supports that feeds it e.g. a wide-aligned cover block with some non-latin chars could do the trick.

I'll try writing a quick unit test for this.

Added a unit test. I also discovered that I needed to add a line to convert HTML entities back to UTF-8 (after $dom->saveHtml()) in order to make sure we feed UTF-8 in, we get UTF-8 (not entities) out.

FWIW, cherry-picked the unit test commit on top of master, ran them: They fail the block content check that I added, just like they should 🎉