Capybara: Chrome 75+ drag_to no longer works

[trcarden]

Meta

Capybara Version:

• capybara (3.24.0)
• webdrivers (4.0.1)
• Webdrivers Updated to chromedriver 75.0.3770.90
• Browser: chrome Version 75.0.3770.100

Expected Behavior

Before chrome 75 (perhaps a few versions before, we had our chrome version locked on CI) drag_to would correctly drag the first sortable-list-item to the second.

Actual Behavior

Nothing happens. No stacktrace, no javascript errors in the console, no obvious issue when debugging. (Note: this code is not using the HTML5 drag APIs).

Steps to reproduce

   <ul class="sortable-list" data-js-hook="sortable-list">
      <li class="sortable-list-item clearfix" data-sortable-id="73">
        <i class="drag-handle material-icons">drag_handle</i>
        <span class="sortable-name">A</span>
      </li>
      <li class="sortable-list-item clearfix" data-sortable-id="74">
        <i class="drag-handle material-icons">drag_handle</i>
        <span class="sortable-name">B</span>
      </li>
  </ul>

    occasion_li_1 = page.find('.sortable-list-item:nth-child(1)')
    occasion_li_2 = page.find('.sortable-list-item:nth-child(2)')
    occasion_li_2.drag_to(occasion_li_1)

[twalpole]

Capybara 3.23 made some changes around the drag code - could you please try Capybara 3.22 and see if dragging works with that. Beyond that Chromedriver 75+ now defaults to w3c mode, can you try disabling the w3c mode in your driver registration and see if that makes it work.

In your description you state it would drag the first to the second, but your example code drags the second to the first, I'm assuming that's just a typo. What library are you using to provide the dragging behavior (and how are you configuring it)?

[twalpole]

Based on the element class names - it's possible you're using SortableJS for the drag behavior (which does actually use HTML5 dragging under the hood if the browser supports it). If you are using SortableJS - https://gist.github.com/twalpole/be9ccd5c4dd356a9e3b627040b882a12 - is an example showing it working with Capybara, if you can modify that code to illustrate the issue you're having then I have somewhere to start looking from.

[trcarden]

We are doing an upgrade on a few of our javascript systems and still use Dragula (https://github.com/bevacqua/dragula). Turns out that changing to Capybara 3.22 had no effect. However toggling to w3c: false did the trick for me.

If anyone else stumbles on this I found out how to toggle that from here: https://stackoverflow.com/questions/56452798/how-to-turn-off-w3c-in-chromedriver-to-address-the-error-unknown-command-cannot

Capybara.register_driver :no_w3c do |app|
  options = Selenium::WebDriver::Chrome::Options.new
  options.add_option('w3c', false)
  Capybara::Selenium::Driver.new(app, browser: :chrome, options: options)
end

If you are using a recent Rails version you can use this: https://github.com/rails/rails/pull/35081/files

@twalpole thank you for world record speed responding to this issue request. Do you have a recommendation for making this work with w3c set to true? It seems like that would be the optimal thing to do now that the defaults have changed

[twalpole]

@trcarden Without knowing exactly what events Dragula is looking for it's tough to say - and I'm not really sure what changes in the W3C mode would affect this. If you can modify the gist I provided to produce the issue I'd have something to investigate further.

[twalpole]

Hmm -- one change between W3C mode and non-W3C mode is that the actions API in W3C mode no longer automatically scrolls elements into view. Capybara has code to scroll if it's needed, but maybe that's not working right with Dragula. Are both the source and target in the viewport when you call drag_to? If not try doing page.scroll_to(occasion_li_1, align: :center) first and seeing if that makes a difference

[trcarden]

@twalpole Ok got it all hooked up and ready for you: https://gist.github.com/trcarden/380d3d2e345a7536e8ae8c2a0a2c13a0

I have to say really like that test harness: super easy and quite efficient.

Also I don't think it has to do with the scrolling (both items are in the viewport)

[twalpole]

Ok, I’ll take a look at this tomorrow - gotta get some sleep before an interview tomorrow

[twalpole]

@trcarden I just took a look at your reproduction case, and it appears to be a bug in chromedriver/Chrome. There is a slight difference in the mouse events generated between w3c and non-w3c mode

 w3c : down, over, move, up
 non: down, over, move, over, up

but that's not what's causing the current issue. The current issue is that the mouse state is lost between actions api executions leading to the mousemove event buttons parameter being 0 - so Dragula releases the drag. This wouldn't be an issue if Capybara executed the down, move, release in one Actions API call, but doing that would prevent detecting dynamic usage of HTML5 drag/drop and the ability to drag to an element that requires scrolling. I need to think about whether there's a way to work around this, or it may have to wait for a fixed chromedriver.

[twalpole]

https://bugs.chromium.org/p/chromedriver/issues/detail?id=2981

[twalpole]

@trcarden Please try the master branch and see if it fixes the issue for you in w3c mode. It should fix the issue as long both elements are in the viewport when dragging. Unfortunately I don't think there's a workaround if scrolling is required during the drag.

[twalpole]

Closing this - workaround will go out in the next release - probably later today

[twalpole]

Workaround for while in w3c mode has been released in 3.25.0 - Full fix will be in chromedriver 77

[trcarden]

@twalpole thank you for all the help! 3.25.0 looks like its working well.