Conversation
| The [=matched capability serialization algorithm=] for the "<code>enableDragAndDrop</code>" capability, | ||
| with parameter |value| is: | ||
|
|
||
| 1. If |value| is false, the [=endpoint node=] must disable [=drag |
There was a problem hiding this comment.
I think this is too broad: we don't want to disable drag and drop for other sessions and/or regular user input. I believe we only want to make sure that the actions dispatched by the WebDriver BiDi client don't get converted into a drag and drop, right?
There was a problem hiding this comment.
Sadly the problem is drag and drop must be completely disabled on the endpoint. This is because while drag and drop is happening, all inputs (other sessions, regular user input, etc) gets ignored.
There was a problem hiding this comment.
Also, it's impossible to separate regular user input and BiDi input for drag and drop. The reason is that drag and drop is predominantly a OS API, meaning when it happens, you must either delegate it to the OS or delegate it to the browser (similar to how Chromium does it). You cannot have both control it at the same time since the OS expects to be able to end the drag itself.
|
Why would this be a capability? People are going to be confused when they try drag and drop and it doesn't work natively. |
|
It looks like we would not need anything like this if implementations pass WPT tests for drag and drop: https://wpt.fyi/results/webdriver/tests/bidi/input/perform_actions/pointer_mouse.py?label=master&label=experimental&aligned&q=webdriver Given that this item got a high priority in the roadmap, let's discuss in the next WG meeting if it makes sense to include drag and drop as an explicit milestone into the roadmap. |
|
My expectation is that if this becomes a capability most, if not all, clients would likely have this set to true for all sessions as it will be pretty poor DX to have to figure out why the commands fail to do what we want. WebDriver classic already passes drag and drop if it is a JS driven drag/drop. I raised a issue a few years ago to get the HTML version with |
|
And to add using a capability would mean the setting is sticky and a client would have to create a new session to actually flip the value. I agree that this is not a solution that we should favor. Overall this should have been discussed first (and now I see the needs-discussion label added to the actual referenced issue). |
Fixed: #487
Preview | Diff