Unexpected behaviour involving Drag & Drop, Shadow DOM with delegateFocus=true
Reported by
simon.si...@gmail.com,
May 25 2017
|
|||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:53.0) Gecko/20100101 Firefox/53.0 Steps to reproduce the problem: * Open up the attached HTML document. * Try dragging each of the green boxes. Result: The first 2 cases work, the 3rd doesn't. What is the expected behavior? All of the green boxes should be draggable. What went wrong? I'll explain the test cases. The first test case is just a box with draggable=true and located directly in the DOM, no Shadow DOM or custom elements are in the way. It works. You can drag it. The second test case is also draggable. It is the same the first except that the box is surrounded by a custom element with a shadow DOM and delegatesFocus=true. The shadow DOM contains a single DIV and SLOT. The 3rd test case doesn't work. It is the same as the second with one difference. The shadow DOM also contains an input field. The presence of this focusable element is enough to prevent the drag operation from working. To me, this is unexpected and wrong. Note: Setting delegatesFocus=false in the 3rd test case 'fixes' it. Making the green box focusable by adding a 'tabindex' attribute also 'fixes' it. Did this work before? N/A Does this work in other browsers? N/A Chrome version: 57.0.2987.133 (64-bit) Channel: stable OS Version: Ubuntu 16.04 Flash Version: Shockwave Flash 25.0 r0
,
May 25 2017
kochi@, could you take a look?
,
May 25 2017
Confirmed the repro, and will investigate what went wrong.
,
May 27 2017
I've also noticed in case 3 that if you make it focusable via tabindex then it works. But if you then listen to the 'focus' event on that element and in the handler use 'otherElement.focus()' to move focus away, then it breaks again. In other words, Chrome *really* wants that element to have the focus otherwise no drag for you. What is funny though, is that if you reassign the focus via the focus event with a setTimeout(0) in between, then the drag still works.
,
May 29 2017
Adding nzolghadr@ in cc. I took a look at this today and found that on the failure case (#3), dragging doesn't start but focus happens. In MouseEventManager::HandleMouseFocus(), 1. search its parent until it finds any focusable element 2. try setting focus on it and if success, return kHandledSystem 3. return kNotHandled otherwise On the failure case (#3), 2. succeeds (focus goes to the <input>) and the following code doesn't handle drag start. On the other hand, the success case (#2), 2. fails and dragging starts. I'm not familiar with drag&drop, I'm not so confident what is the expected behavior. Looks like both focusable and draggable element can be dragged - e.g. <button draggable="true">Hello</button> can be dragged. nzolghadr@ (looks like you touched code around this recently), any advice on this?
,
May 29 2017
Tentative CL: return kNotHandled in case delegatesFocus + shifting focus succeeded. https://chromium-review.googlesource.com/c/517685/
,
May 29 2017
Victor might have a better idea here.
,
Oct 17 2017
bulk edit to remove owner=me where I'm not actively looking at.
,
Oct 17 2017
mark it available.
,
Oct 17
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 18
Still an issue in 2018 Q4 check-in. |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by dominicc@chromium.org
, May 25 2017