Issue metadata
Sign in to add a comment
|
oopif events: drag-and-drop can target the wrong view |
||||||||||||||||||||
Issue descriptionDuring drag-and-drop, we try to find the view under the cursor to determine whether the view under the cursor can accept the drag [1] (and update the cursor accordingly), and on drop, we find the view under the cursor that should receive the dropped content [2]. Both of these use the synchronous version of the hit-testing API, which does not always return the correct target when OOPIFs are involved. To find the correct target in such cases, we need to use the async targeting API (i.e. mojom.InputTargetClient, or RenderWidgetTargeter [3]). Using the async API itself should not be difficult, but changing the dnd-code in chrome to accept some of these operations to happen asynchronously will likely be the trickier part. [1] https://cs.chromium.org/chromium/src/content/browser/web_contents/web_contents_view_aura.cc?l=1291 [2] https://cs.chromium.org/chromium/src/content/browser/web_contents/web_contents_view_aura.cc?l=1357 [3] https://cs.chromium.org/chromium/src/content/browser/renderer_host/render_widget_targeter.h?l=50
,
Nov 28
kenrb@, is there any plans to get drag-and-drop working with OOPIFs?
,
Dec 14
,
Dec 18
Hi Ken, should this bug also be re-assigned to dcheng@? Thanks!
,
Jan 8
Hi Daniel, I was wondering if you would have some bandwidth to look at this or know the best owner for this bug? Thanks!
,
Jan 8
I don't have the bandwidth to look at this currently, but I can help with reviews. In general though, DnD expects things to be generally sync today, though for drag updated stuff, it might be OK to give a slightly inaccurate response (i.e. we cache the last seen accept/reject status and report that). Drop will be harder though; we cheat with some heuristics, but it's not perfect.
,
Jan 9
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1a118643f1c88c760ed0673a825cbe497ea21c02 commit 1a118643f1c88c760ed0673a825cbe497ea21c02 Author: Sadrul Habib Chowdhury <sadrul@chromium.org> Date: Wed Jan 09 19:27:20 2019 dnd: Measure how often chrome accepts drag-drops. Measure how often chrome accepts or rejects a drop operation during a drag-and-drop session. This metric can inform whether chrome should always accept the drop from the OS. This would allow chrome to use asynchronous targeting to find the correct target, and update the cursor etc. afterwards as needed. BUG=804633 Change-Id: Idc439f39bae56c8d02a920440c0806795847479e Reviewed-on: https://chromium-review.googlesource.com/c/1401226 Commit-Queue: Sadrul Chowdhury <sadrul@chromium.org> Reviewed-by: Robert Kaplow <rkaplow@chromium.org> Reviewed-by: Daniel Cheng <dcheng@chromium.org> Cr-Commit-Position: refs/heads/master@{#621264} [modify] https://crrev.com/1a118643f1c88c760ed0673a825cbe497ea21c02/tools/metrics/histograms/histograms.xml [modify] https://crrev.com/1a118643f1c88c760ed0673a825cbe497ea21c02/ui/views/widget/desktop_aura/desktop_drag_drop_client_aurax11.cc [modify] https://crrev.com/1a118643f1c88c760ed0673a825cbe497ea21c02/ui/views/widget/desktop_aura/desktop_drop_target_win.cc [modify] https://crrev.com/1a118643f1c88c760ed0673a825cbe497ea21c02/ui/views_bridge_mac/bridged_content_view.mm
,
Jan 9
I will check back on the UMA data in ~3 weeks and see if it would make sense to always accept drag-updates and use async targeting.
,
Jan 10
Assigning to sadrul@ per the comment above.
,
Jan 10
|
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by nasko@chromium.org
, Jan 23 2018