Plugin: Backport bug fixes from Gutenberg 5.5.0 to wp/trunk (WordPress 5.2 RC)

[aduth]

This pull request seeks to backport the following bug-fix pull requests from Gutenberg 5.5.0 to the wp/trunk branch, to be published as part of a subsequent packages release and patched into core ahead of this Wednesday's WordPress 5.2 release candidate.

• Fix memize option key typo #14750 (@ellatrix)
• Fix/post title borders in code editor #14771 (@kjellr)
• Fix: Restrict block insert, move, and replace attending to allowedBlocks, locking, and child blocks #14003 (@jorgefilipecosta)
• Make image selected onFocus #14813 (@nosolosw)
• Fix Blocker Picker autocompleter icon spacing #14772 (@getdave)
• Data: Return result of middleware chain in resolvers cache middleware #14711 (@aduth)
• Avoid saving metaboxes before a preview #14877 (@talldan)
• Add publish step to preview with custom fields test #14894 (@talldan)
• Fix selecting separator block #14854 (@ashwin-pc)
• Color palette settings button hover tootlip fix. #14693 (@nicolad)
• Refactor the Settings button CSS. #14475 (@afercia)
• Input Interaction: take into account container padding #14804 (@ellatrix)
• Fix regression with column block being selected. #14876 (@jasmussen)
• Block Editor: Consider received blocks state change as ignored #14916 (@aduth)
• Block gallery: delete image with delete or backspace keys #14822 (@nosolosw)
• Fix button isDefault isBusy hover #14469 (@sbardian)
• Fix regression with color swatch focus style #14944 (@jasmussen)
• Remove box shadow from the default appender inserter button hover state #14936 (@kjellr)
• Adjust clashing shortcuts used for character input #14681 (@ellatrix)
• Button Block: fix space insertion #14925 (@ellatrix)
• Format Library: Assign Popover anchorRect to update selection position #14938 (@aduth)
• Fix spacer NaN warning #14785 (@Jackie6)
• Block Editor: Assign Provider isSyncingOutcomingValue only when blocks changing #14955 (@aduth)

Process Notes:

Roughly following steps from:

https://github.com/WordPress/gutenberg/blob/master/docs/contributors/release.md#minor-wordpress-releases

I wrote a small Node script to generate cherry-pick commands to ensure each pull request was applied in the order of their merge date:

https://gist.github.com/aduth/901b1604dc7a9ba520db0a06deadec05

And a variant to generate the above list of pull requests and corresponding authors:

https://gist.github.com/aduth/65edee20b936a21e086dcc6f60bbb3e8

There were a few issues encountered in the process of applying cherry-picked commits:

Conflicts:

• b149150 (Fix regression with column block being selected. #14876, cc @jasmussen, applied as 385fbd2112b9cb5310dd7981e7281f14f94b9f7e) - Simple conflict on proximity to more recent additions of columns vertical alignment styling
• 8722f49 (Block Editor: Consider received blocks state change as ignored #14916, cc @aduth, applied as 41227759091a5d87e3e70d4181667241567206a5) - Included updates for tests to new inner blocks replacements not present in wp/trunk
• 6a26e36 (Format Library: Assign Popover anchorRect to update selection position #14938, cc @aduth, applied as b6cf972480a4165b92817aa8a5c81e488f2169fe) - Changelogs
• e167221 (Fix spacer NaN warning #14785, cc @Jackie6, applied as c0b29a79a07c21346881584f3731054cabbc7af6) - The component had previously been moved from index.js to edit.js. The conflict was resolved by approximating the commit as if it had applied to index.js.

Not Included:

• Fix memize option key typo #14750 (cc @ellatrix) appears to have already been merged to trunk in Merge bug fixes into wp/trunk #14796. I still think it was a Gutenberg 5.5 fix, perhaps pulled early into the last back-port?
• Block Editor: Consider received blocks state change as ignored #14916 (cc @aduth) fixed an bug introduced as part of a feature not present in wp/trunk (i.e. was never an issue in WordPress 5.2 because it affects a feature introduced more recent than feature freeze)

Testing Instructions:

Verify fix of impacted pull requests.

Ensure tests pass.

[youknowriad]

Can we enable the e2e tests on these branches?

[youknowriad]

(you shouldn't have named the branch wp/* because these are protected :)

[youknowriad]

I'm still seeing a border in the post-title in the code editor which is supposed to be fixed by this #14771 (might be a markup conflict)

[youknowriad]

I'm seeing an issue where the columns block is not functional. I don't see any "column" block inserted.

[jasmussen]

Are you looking at the markup? Because until we have better parent selection, selecting the column with the mouse has intentionally been disabled.

[youknowriad]

@jasmussen not really, just inserting a columns block and trying to insert content is broken.

[youknowriad]

So I tested almost all the fixes here, everything seems fine. The only concerning issue is the columns block.

[jasmussen]

#14876 for posterity.

[aduth]

I'm seeing an issue where the columns block is not functional. I don't see any "column" block inserted.

By the noted conflict, there were some substantial updates not included yet in trunk from #13899. Unclear if or how much #14876 might rely on those changes.

Occurring to me now that Travis builds aren't running here. I'd have imagined some end-to-end failures would be reflected in the issues you're discovering. Might need to be run manually in local environment instead.

[aduth]

From some initial debugging, the issues with columns block appear to stem from #14003 . Specifically, the initialization of the columns block in inserting individual Column blocks is considered as invalid:

https://github.com/WordPress/gutenberg/pull/14003/files#diff-90854747cb48848ced1cc6f1700d8b66R397

Unclear yet why this works in master and not in this branch.

[aduth]

Oh, I see now. It relies on #14291, which was never introduced to wp/trunk because it was considered a feature, but is necessary for Columns to work correctly when including the changes from #14003 (it substitutes the implementation of the mapDispatchToProps for InnerBlocks to use custom logic in place of insertBlocks).

I might suggest then one of two options for moving forward:

• Cherry-pick Update: Use new action REPLACE_INNER_BLOCKS for InnerBlocks replacement #14291
• Drop cherry-picking of Fix: Restrict block insert, move, and replace attending to allowedBlocks, locking, and child blocks #14003

cc @jorgefilipecosta

[aduth]

(you shouldn't have named the branch wp/* because these are protected :)

Is there any way to change it now? Is it documented somewhere, or should I follow-up with a task for that?

[aduth]

I might suggest then one of two options for moving forward:

• Cherry-pick Update: Use new action REPLACE_INNER_BLOCKS for InnerBlocks replacement #14291
• Drop cherry-picking of Fix: Restrict block insert, move, and replace attending to allowedBlocks, locking, and child blocks #14003

In some initial testing of dropping the commit from #14003, it does resolve the behavior of the columns not being added, but there appears to be some other issue with being able to select the blocks themselves (perhaps related to #14876, as the symptom is very much of the sort impacted by pointer-events styling).

[youknowriad]

Is there any way to change it now? Is it documented somewhere, or should I follow-up with a task for that?

I think once we merge this PR, we should disable the protection, remove the branch and enable the protection again. This is not documented, but we have the same with release/* branches. Maybe we could document protected branches.

[youknowriad]

Can we try backporting #14291 as well?

[aduth]

I've pushed a rebased branch which includes the following:

• Cherry-picked 1936caa from Update: Use new action REPLACE_INNER_BLOCKS for InnerBlocks replacement #14291 to fix behavior of adding initial Column blocks to a new Columns block.
• Applied manual edits to the commit ad7095b (Fix regression with color swatch focus style #14944) to fix column selection. Notably, the original commit b149150 included a reference to the class name .block-core-columns† which was introduced in Core Columns Block - adds ability to vertically align all the columns #13899, which isn't included in trunk. As can be seen in my revised commit, I removed the class selector, and the behavior (including the affected regression intended to be fixed) is restored. I'd like a second opinion from @jasmussen in case one or the other of (a) the lowered specificity by the removed selector or (b) the selector .block-core-columns was needed in some way to contextualize the subsequent .block-editor-block-list__layout.

† Aside: This class name does not seem conventional.

I think once we merge this PR, we should disable the protection, remove the branch and enable the protection again. This is not documented, but we have the same with release/* branches. Maybe we could document protected branches.

I ran into issues force-pushing the rebase due to the protection rules. I updated them to two separate rules wp/?.? and wp/trunk to allow me to push, which could perhaps be a general improvement anyways. Otherwise, I can restore the original rule after.

[jasmussen]

I'd like a second opinion from @jasmussen in case one or the other of (a) the lowered specificity by the removed selector or (b) the selector .block-core-columns was needed in some way to contextualize the subsequent .block-editor-block-list__layout.

I wish I had found out exactly what made the old stopgap fix (to prevent the selection of the column block) break. To the best of my knowledge, what made it break was that the CSS selector was incredibly specific and used adjacent sibling selectors, and then a separate refactor of either the block list or the columns block added an additional element to the hierarchy — could be a fragment or anything — making it break. But I'm not sure.

The new fix is much simpler, less specific, and incidentally should affect pointer events less so than the old one due to the reduced specificity. From looking at the code, it looks correctly ported. But the way to test is to insert a columns block, and be sure to test both an archives block, and a reusable block as nested elements inside the columns block. Both archives and reusable blocks use the component-disabled component which also disables pointer events, those should remain disabled despite what the columns block does.

[jorgefilipecosta]

I noticed there are some unit test fails in this branch:

  ● state › blocks() › replace inner blocks › can replace a child block

    expect(received).toEqual(expected)

    Difference:

    - Expected
    + Received

    @@ -16,11 +16,12 @@
            "clientId": "chicken",
            "isValid": true,
            "name": "core/test-parent-block",
          },
        },
    -   "isPersistentChange": Anything,
    +   "isIgnoredChange": false,
    +   "isPersistentChange": true,

It seems the test case is not aware of isIgnoredChange that was meanwhile added.

[aduth]

@jorgefilipecosta Good catch. Noted in the original comment, I had some conflict with these tests in 8722f49 (#14916). At the time I wasn't bringing in changes from #14291. I'll try cherry-picking the commit again.

It also reminds me to run all tests again locally, since as noted above, Travis is not running against this branch.

[jorgefilipecosta]

I think the root cause of the test failure is that I should have used toMatchObject to allow future additions of keys in the reducer not relevant to the test case. I can submit a PR with these changes to tests that can be merged to master and cherry-picked to this branch if the problem persists.

[aduth]

@jorgefilipecosta Good catch. Noted in the original comment, I had some conflict with these tests in 8722f49 (#14916). At the time I wasn't bringing in changes from #14291. I'll try cherry-picking the commit again.

I rebased locally and substituted the original 8722f49 for where in the branch I'd previously made revisions in 215f7f2 to account for conflicts. The commit applied cleanly (unlike before) and all unit tests passed.

I'm going to run through the end-to-end tests locally, but will push the rebased branch afterward.

[aduth]

Pushed the rebased branch. I had some initial trouble with the end-to-end tests related to the fact that #14243 hadn't been fixed in wp/trunk. Temporarily bringing it into the branch helped demonstrate that all tests are passing.

[youknowriad]

This is looking good in my manual tests.

[aduth]

I'm still seeing a border in the post-title in the code editor which is supposed to be fixed by this #14771 (might be a markup conflict)

I could not reproduce this. In Firefox, I see that the border is thicker on the left side than it is in Chrome (screenshot), but I see this in master as well.

[aduth]

Publish results:

Successfully published:
 - @wordpress/[email protected]
 - @wordpress/[email protected]
 - @wordpress/[email protected]
 - @wordpress/[email protected]
 - @wordpress/[email protected]
 - @wordpress/[email protected]
 - @wordpress/[email protected]
 - @wordpress/[email protected]
 - @wordpress/[email protected]
 - @wordpress/[email protected]
 - @wordpress/[email protected]
lerna success published 11 packages

Trac ticket: https://core.trac.wordpress.org/ticket/46951