Grid Layout interactivity issues with resizer box

[andrewserong]

Description

Part of #57478

This issue captures a couple of the issues I encountered while testing the grid interactivity experiment in trunk. With the Grid Interactivity experiment activated, I noticed the following issues:

• In the site editor, when dragging a child of the Grid block, the dimensions of the resizer aren't correct (this appears to be due to styling conflicts with the editor's resizable box)
• In the post editor, when iframed, the dimensions and limits of the resizeable boxes are also sometimes incorrect
• There appears to be a potential memory leak or infinite loop when going to drag a block to span multiple columns, but the user lets go of the drag handle at the original bounds of the block

Step-by-step reproduction instructions

Using the following grid markup:

Grid markup

<!-- wp:group {"layout":{"type":"grid","columnCount":3,"minimumColumnWidth":null,"rowCount":"3"}} -->
<div class="wp-block-group"><!-- wp:paragraph {"style":{"layout":{"columnSpan":1,"rowSpan":1}},"backgroundColor":"accent-4"} -->
<p class="has-accent-4-background-color has-background">A paragraph</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph {"backgroundColor":"accent-4"} -->
<p class="has-accent-4-background-color has-background">Another paragraph</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph {"backgroundColor":"accent-4"} -->
<p class="has-accent-4-background-color has-background">Another one</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph {"style":{"layout":{"columnSpan":1,"rowSpan":1}},"backgroundColor":"accent-4"} -->
<p class="has-accent-4-background-color has-background">A paragraph</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph {"backgroundColor":"accent-4"} -->
<p class="has-accent-4-background-color has-background">Yet another</p>
<!-- /wp:paragraph --></div>
<!-- /wp:group -->

<!-- wp:paragraph -->
<p></p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p></p>
<!-- /wp:paragraph -->

Test the following:

• In the site editor
• In the post editor while iframed (i.e. custom fields boxes are switched off) try dragging the handles on each of the boxes. For me, the first grid child can't be dragged much further than its size, and when selecting and dragging on the last child, the dimensions are off (see screengrabs below)
• In the post editor while not iframed (i.e. custom fields boxes are switched on), try the above — this worked much better for me, but I noticed if I drag the right drag handle on the last grid child to stretch to the right but let go over the area of the original position of the right hand side of the block, then the editor freezes

Screenshots, screen recording, code snippet

Screengrab of incorrect dimensions and limits of the resizer in the post editor while iframed:

2024-05-13.16.22.32.mp4

Screengrab of editor freezing in the post editor while not iframed:

2024-05-14.09.04.40.mp4

Environment info

No response

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[tellthemachines]

Ok so I think there are three separate issues here:

• The site editor resizer bug, which happens when trying to resize vertically (the left and right handles are in the wrong position, but it doesn't affect the actual resizing)
• A bug with the right resize handle, which so far I can only repro in the site editor, which prevents resizing to the right altogether (right and left handles seem to shrink inwards) though resizing to the left works fine
• The non-iframed post editor bug is related to the event listener set on the body element; if we can detect whether the editor is iframed we could maybe add some different logic to deal with it (can we detect that? I'm not sure)

[andrewserong]

Thanks for breaking them out 👍
In case it helps, I've found the post editor locking up issue a bit tricky to reproduce in a reliable way. It usually takes me a few times dragging a col or row span before it breaks when dragging back to the original size.

[tellthemachines]

In my local testing, moving the event listener to .editor-styles-wrapper instead of body seems to fix the non-iframed editor issue. I'll put up a PR.

Another issue I noticed in non-iframed is the top and bottom bounds aren't corrent, I think because contentRef is always null, so it's using the fallback height difference, which of course doesn't apply if the editor isn't iframed. I think that was why I originally added the ref to a dummy element instead of passing it to the resizer; might be better to bring that back.

[andrewserong]

I'll close this out now that the issues have been resolved in #61636, #61641, and #61643. Thanks for the quick work on this everyone!