-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix drag and drop in chrome when the document has iframes #9511
Conversation
Note that #9311 refactors the |
@@ -57,6 +64,13 @@ class Draggable extends Component { | |||
this.cursorTop = event.clientY; | |||
} | |||
|
|||
onDrop( ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that, as per the spec and tested in practice, the drop
event is fired before the dragend
event. So, an alternative approach to fix this would be to use the drop
event in every case, as it is fired reliably AFAIK. That would require changing Draggable
API to use the onDrop
instead.
Because this bug only affect Chrome if the document has iframes, I feel more comfortable trying to limit the hack to that particular use case. I hope the Chrome team fix this at some point and if they do, we can remove the hack without affecting Draggable
's API.
@@ -15,14 +15,20 @@ const cloneWrapperClass = 'components-draggable__clone'; | |||
const cloneHeightTransformationBreakpoint = 700; | |||
const clonePadding = 20; | |||
|
|||
const isChromeUA = ( ) => /Chrome/.test( window.navigator.userAgent ); | |||
const documentHasIframes = ( ) => [ ...document.body.querySelectorAll( 'iframe' ) ].length > 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shall we scope the iframe search to the .editor-block-list__layout
element? I fear that if we do that it would break at some point if we decide to change the CSS classes we use.
Also, I'm not aware of any other areas that could potentially use iframes outside the editor. Is there any? If so, this would give false positives.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should scope the search at least to the #editor
element. The WordPress.com notifications bar uses an iframe.
See https://bugs.chromium.org/p/chromium/issues/detail?id=737691#c8 In Chrome, the dragend won't be dispatched is an iframe is affected by the drag operation (moved as a result of dragging other nodes, etc).
1d8bf51
to
24241c7
Compare
Tested and confirmed the fix but I think design wise, it's not great. I wonder if we should show the block icon as a drag handle instead of removing the iframes which can cause weird states. cc @jasmussen |
Oh I guess the iframe removal is already in master, so I guess I'm just going to approve here and we'll see if we can improve the drag handle for blocks with iframes later. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
Given designs, perhaps we should merge this along wiht the improvements that are scheduled in |
Fixes #6145
In Chrome, the
dragend
event won't be dispatched if an iframe is affected by the drag operation (moved as a result of dragging other nodes, etc). Chrome bug.Testing
The expected result is that the drag-and-drop operation works and it's not stuck mid-drag.