-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
List View: Ensure onBlockDrop does not fire if there is no target #52959
List View: Ensure onBlockDrop does not fire if there is no target #52959
Conversation
Size Change: +5 B (0%) Total Size: 1.44 MB
ℹ️ View Unchanged
|
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.
I can't reproduce the error unfortunately, but it makes sense to fire the handler on if there's a target to work with.
👍🏻
Thanks for reviewing! I think it's a fairly uncommon / difficult thing to reproduce due to it being a subtle race condition that's usually resolved within about |
I just cherry-picked this PR to the update/packages-wp-6-3-RC3 branch to get it included in the next release: 12fcd6b |
* Patterns: Enable focus mode editing (#52427) * PreventDefault when isComposing is true. apply patch from t-hamano. (#52844) see: #52821 (comment) * List View: Ensure onDrop does not fire if there is no target (#52959) * I18N: Add missing Gettext wrapper on strings in Edit Post overview sidebar (#52971) * I18N: Add missing gettext wrapper * Add context to disambiguate 'Outline' that is commonly used on borders. * Footnotes: disable based on post type (#52934) * Footnotes: disable based on post type * Address feedback * Fix typo * Format: disable if block is not registered * Lock usesContext api * Use Symbol instead of Math.random * Patterns Browse Screen: Fix back button when switching between categories (#52964) * Patterns: Allow orphaned template parts to appear in general category (#52961) * Spacing presets: fix bug with select control adding undefined preset values (#53005) * Site Editor: Fix canvas mode sync with URL (#52996) * Check if spacing tool is defined before displaying controls. (#53008) * Check if spacing tool is defined before displaying controls. * Don't show sides if spacing type false * Improve consistency of the Post editor and Site editor Document actions (#52246) * Remove redundant shortcut button. * Fix focus and hover style and improve consistency. * Rename post document-title and improve CSS consistency. * Site Editor: Fix the typo in the title label map (#53071) * Fix patterns search crash: check for existence of defaultView before attempting to get styles (#52956) * backport paging bug fixes (#53091) --------- Co-authored-by: George Mamadashvili <[email protected]> Co-authored-by: Hiroshi Urabe <[email protected]> Co-authored-by: Andrew Serong <[email protected]> Co-authored-by: Pedro Mendonça <[email protected]> Co-authored-by: Ella <[email protected]> Co-authored-by: Aaron Robertshaw <[email protected]> Co-authored-by: Glen Davies <[email protected]> Co-authored-by: tellthemachines <[email protected]> Co-authored-by: Andrea Fercia <[email protected]>
What?
Fixes: #52919
Fix issue with the List View's drag-and-drop where sometimes blocks would suddenly be sent down to the bottom of the document when clicking around quickly.
Why?
From some logging out of values, what appears to be happening on
trunk
is that if you click on a selected block very rapidly with a little bit of movement, sometimes anonDragEnd
callback is fired (which setstarget
tonull
), before theonDrop
callback is fired.What's expected to happen is that dragging on a selected block will effectively result in no moving of blocks occurring because the target is the same as what's being dragged over. However, the code that determines the desired target is throttled to
200ms
, so if you go to drag a block and within that200ms
perform another drag, it's possible to fire that second drag after the firstdragEnd
event has cleared out thetarget
and before theonDragOver
gives us a new target.I'm not 100% that this is exactly what's happening, but what I've observed is that if you're clicking around very quickly on a selected block, it seems that you can accidentally drag a block and rapidly start another drag in the same position, and due to this issue of
target
being set tonull
for a short time, the block winds up being sent all the way to the bottom.To resolve this issue (which seems to be something of a race condition to me), we can check that the target is truthy before allowing a drop to occur.
How?
Within the
onDrop
callback, check that thetarget
is truthy before allowingonBlockDrop
to be called. This should be pretty safe as the list view drag and drop behaviour expects that there is a target set for any kind of drop to occur.Testing Instructions
trunk
target
doesn't interrupt drag events that are not about rearranging existing blocks)Screenshots or screencast