Drag and drop indicator line positioning is incorrect in WP Playground #58756
Comments
andrewserong
added
[Type] Bug
|
Note: this issue isn't exclusive to drag and drop — it also affects the inbetween inserter when hovering between blocks. For example, in the following screenshot, this should have displayed above the Image block: 
|
|
The root cause of this issue may be the same as reported #58001 for popover and space visualizer issues. |
|
Thanks @t-hamano! Yes, that helps — sounds like there's a disconnect between the measurements that the popover is using, and then what happens when the positioning is output for it 🤔 |
|
Just in case it helps anyone else with debugging, I can reproduce this issue outside of WP Playground by adding a <!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Test Gutenberg in an iframe</title>
</head>
<body>
<div class="header">
<p>This is a header</p>
</div>
<iframe class="editor" src="http://localhost:8888/wp-admin/site-editor.php" title="Test site">
</iframe>
<style>
.header {
background-color: #f4f4f4;
padding: 20px;
text-align: center;
}
.editor {
width: 100%;
height: 100vh;
border: none;
}
</style>
</body>
</html>That then results in the inbetween inserter rendering lower than expected (the same distance lower at the height of the header area): 
Unfortunately, I haven't had much luck debugging this, and I can't quite work out if it's a recent issue, or a limitation of floating-ui's iframe awareness, in that it sounds like it should be working up the hierarchy of iframes, but perhaps it doesn't consider whether the outer-most document is itself in an iframe? Just pinging @ciampo who previously worked on #46845 which removed the old overrides to offset iframes, and @jsnajdr who worked on a floating-ui fix that was surrounding traversing up into the iframe parent: floating-ui/floating-ui#2535 I wonder if the problem is to do with floating-ui, the popover component, or how we use popover slots? Incidentally, if I force the editor canvas to be rendered without an iframe (by enabling Custom fields in the editor preferences) then the positioning issue doesn't appear. So to isolate the problem it seems to be present when we're measuring an element or position that is within the editor canvas iframe (i.e. blocks in the canvas) and the whole editor itself is iframed (as in WP Playground). |
|
I see you're putting the Site Editor in |
|
Yes this issue can be reproduced easily on storybook https://wordpress.github.io/gutenberg/?path=/story/playground-block-editor--box |
|
This also seems to be an issue with the Block Toolbar location covering part of the block it belongs, too. I originally thought it was a button block regression issue, but when I tested things in a LocalWP environment, it didn't occur. All Screenrecording and screenshot via Playground Attempt.to.edit.the.button.mp4It also happens with other blocks: Example paragraph block + Image block
|
Thanks for confirming, folks! Yes, it's become a higher priority now that Playground use is becoming more prominent. Since it's a very convenient way for folks to test out WordPress and Gutenberg features, I think that's probably why we're seeing more reports of the issue. |
|
I submitted a Floating UI fix here: floating-ui/floating-ui#2785 Let's see what the maintainer says about it. If a new patched version is released, we can upgrade the Gutenberg dependency and that should fix the Playground problem. |
github-actions
bot
added
the
[Status] In Progress
github-project-automation
bot
moved this from 📥 Todo
to ✅ Done
in WordPress 6.5 Editor Tasks
Description
Raised by @annezazu in #58589 (comment): the drop indicator line (
BlockPopoverInbetween) when dragging and dropping into the editor canvas is in the wrong position when using WP Playground.WP Playground renders the editor lower down within the page, with its own chrome added to the top of the page. It appears that this change means that the positioning of the drop indicator line is off.
Ideally, the drop indicator line logic should be resilient to the editor being rendered in a different position to flush against the top of the viewport.
Step-by-step reproduction instructions
Screenshots, screen recording, code snippet
In this screenshot, note how the drop indicator line is lower than the position of the Buttons block we're trying to drag next to:
This doesn't happen in a "normal" Gutenberg/WP environment
Environment info
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
The text was updated successfully, but these errors were encountered: