Repository navigation
fix(drag): end HTML5 drags like a browser and support drop offsets in drag_to - #343
Merged
Merged
Conversation
…owser drag.js fired dragleave right before drop on the target, so Pragmatic drag and drop treated the drag as having left the window and dropped onto nothing. Also fix the entry point from above or below a target and the leaked key global. Capybara's shared spec that requires dragleave alongside drop is skipped.
Measured from the target's center or top left like click, following offset: or Capybara.w3c_click_offset, on both the HTML5 and the mouse path, so drop targets that tell the upper half from the lower one can be driven [#325].
navidemad
added a commit
to navidemad/capybara-lightpanda
that referenced
this pull request
Oct 17, 2026
HTML5_DRAG_JS fired dragleave on the target and then drop when the last dragover was cancelled. A browser fires drop if the target accepted the drag, otherwise dragleave. Pragmatic drag and drop reads a relatedTarget-less dragleave as the drag leaving the window, clears its drop targets and drops onto nothing. Also fixes two port bugs kept on purpose until now: pointOnRect read rectPt.top (a DOMPoint has none, so a target entered from above or below got the source's center as entry point), and key leaked as a global. Ports rubycdp/cuprite#343. Capybara's shared spec 'should preserve clientX/Y from last dragover event' asserts both events, so it is skipped with that reason. Co-authored-by: Claude <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #325.
Summary
drag.jsends a drag like a browser. The target getsdropif it accepted the drag, otherwisedragleave, never both. The script ported from Capybara fireddragleaveright beforedrop. Pragmatic drag and drop reads adragleavewithoutrelatedTargetas the drag leaving the window, clears its drop targets and drops onto nothing.rectPt.topinpointOnRectwas alwaysundefined(so the entry point wasNaNwhen coming from above or below a target), andkeyleaked as a global.drag_to(other, x:, y:, offset:)drops at an offset from the target. It works likeclick: bothx:andy:are required, and the offset is measured from the center or the top left, followingoffset:orCapybara.w3c_click_offset. This works on both the HTML5 simulation and the mouse path, so drop targets that tell the upper half from the lower one can be driven.The JS simulation stays the default for draggable elements, same as Capybara. A real Chrome drag is available with
html5: falsesince Ferrum 0.19.1 (rubycdp/ferrum#646).Capybara's shared spec
#drag_to HTML5 should preserve clientX/Y from last dragover eventrequiresDragLeavetogether withDrop, so it's skipped with that reason.Verification
Against a page using Pragmatic drag and drop with closest-edge hitboxes:
drag_to(c)cdrag_to(c, x: 0, y: -20)/y: 20top/bottomhtml5: falsetop/bottomspec/features/session_spec.rbwithspec/support/views/html5_drag.erb. The accept-target spec fails without the fix, and the 6 offset specs fail without the feature.driver_spec.rb:1783"can get the frames url", also fails onmainwith Ferrum 0.19.1, which no longer passes--disable-web-security(fix(browser): drop --disable-web-security from default Chrome flags ferrum#649). It needs a separate fix.