🤖 Filed by an agent on my behalf.
drag_to(html5: true) (new in 0.18, #315) does not drive Pragmatic drag-and-drop. Same page, same event probe:
Selenium ActionBuilder: mousedown, mousemove, dragstart, dragenter, dragover, drop, dragend -> drop handled
drag_to(html5: true): mousedown, dragstart, dragenter, dragover, dragover, dragleave, drop -> drop NOT handled
drag_to(html5: false): mousedown, mousemove x10, mouseup -> no dragstart at all
Two causes:
drag.js fires dragleave on the target immediately before drop. Browsers don't. Pragmatic releases its drop target on dragleave, so drop lands on nothing. That drop fires at all proves the preceding dragover was preventDefaulted, i.e. the target had been accepted.
- The deciding
dragover/drop are dispatched at the target's centre (dragOnTarget), and drag_to has no offset parameter — so hitbox libraries that resolve "insert above vs below" from the pointer position cannot be driven at all.
Both are inherited from Capybara's HTML5_DRAG_DROP_SCRIPT, and Capybara's Selenium drag_to(html5: true) fails identically, so this is a faithful port rather than a porting bug. Noting it because #315's motivation was letting suites drop Selenium, and for Pragmatic-based UIs it does not yet get there.
Driving CDP drag interception instead does work: Input.setInterceptDrags(true), take the payload from Input.dragIntercepted, then Input.dispatchDragEvent for dragEnter/dragOver/drop at explicit coordinates. Chrome emits genuine, correctly ordered events and honours the coordinates. I spiked this in our suite and a previously Selenium-only Pragmatic drag spec went 7/7 green under Cuprite, at 6.0s against Selenium's 9.2s.
That needs one Ferrum fix first — Mouse#move omits button: on mouseMoved, so no drag ever starts: rubycdp/ferrum#635.
Would a real-drag path for drag_to (plus some way to aim at a point rather than the target's centre) be welcome here? Happy to work it up as a PR.
Cuprite 0.18, Ferrum 0.18.0, Chrome 140.
🤖 Filed by an agent on my behalf.
drag_to(html5: true)(new in 0.18, #315) does not drive Pragmatic drag-and-drop. Same page, same event probe:Two causes:
drag.jsfiresdragleaveon the target immediately beforedrop. Browsers don't. Pragmatic releases its drop target ondragleave, sodroplands on nothing. Thatdropfires at all proves the precedingdragoverwaspreventDefaulted, i.e. the target had been accepted.dragover/dropare dispatched at the target's centre (dragOnTarget), anddrag_tohas no offset parameter — so hitbox libraries that resolve "insert above vs below" from the pointer position cannot be driven at all.Both are inherited from Capybara's
HTML5_DRAG_DROP_SCRIPT, and Capybara's Seleniumdrag_to(html5: true)fails identically, so this is a faithful port rather than a porting bug. Noting it because #315's motivation was letting suites drop Selenium, and for Pragmatic-based UIs it does not yet get there.Driving CDP drag interception instead does work:
Input.setInterceptDrags(true), take the payload fromInput.dragIntercepted, thenInput.dispatchDragEventfor dragEnter/dragOver/drop at explicit coordinates. Chrome emits genuine, correctly ordered events and honours the coordinates. I spiked this in our suite and a previously Selenium-only Pragmatic drag spec went 7/7 green under Cuprite, at 6.0s against Selenium's 9.2s.That needs one Ferrum fix first —
Mouse#moveomitsbutton:onmouseMoved, so no drag ever starts: rubycdp/ferrum#635.Would a real-drag path for
drag_to(plus some way to aim at a point rather than the target's centre) be welcome here? Happy to work it up as a PR.Cuprite 0.18, Ferrum 0.18.0, Chrome 140.