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. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Adding bsittler for spec knowledge. Unsure what should happen here.

(and victor & josh)

The actual HTML spec (https://html.spec.whatwg.org/multipage/dnd.html#drag-and-drop-processing-model) says:

"From the moment that the user agent is to initiate the drag-and-drop operation, until the end of the drag-and-drop operation, device input events (e.g. mouse and keyboard events) must be suppressed."

It then goes on at considerably more length and in more depth than the non-authoritative web page quoted in #0

Does the current HTML specification adequately address the issue you raised?

RE: Unsure what should happen

third_party/WebKit/Source/core/frame/WebFrameWidgetImpl.cpp suppresses *some* input events if drag and drop is in progress:

    WebInputEventResult WebFrameWidgetImpl::HandleInputEvent(
        const WebCoalescedInputEvent& coalesced_event) {
    ...
      // If a drag-and-drop operation is in progress, ignore input events.
      if (doing_drag_and_drop_)
        return WebInputEventResult::kHandledSuppressed;

The problem is that only events covered by this particular WebFrameWidgetImpl will be suppressed.
- Events in OOPIFs won't be suppressed (*)
- Events in other windows won't be suppressed (*)
(*) except in Windows where the suppression is handled at the OS-level

OTOH, at this point I don't remember specific repro steps that show non-drag-related input events during a drag... :-/  I think I've seen mouse events on Linux, but this was long time ago so I might be misremembering.  And when I today try DragAndDropBrowserTest I don't see any mouse events between dragstart and dragstop.  I am also not sure if events can possibly be delivered to another window [or rather - another WebFrameWidgetImpl] than the one that is being dragged over but maybe this is indeed possible (multiple mouse pointers?  touch during drag?  input events injected by accessibility software at the OS level?)


RE: Does the current HTML specification adequately address the issue you raised?

I can't tell from your spec quote whether the spec meant suppression at the scope of 1/2/3 and/or a/b/c (see comment #0).  Can you please clarify i) if you think the spec means 1/2/3 and/or a/b/c and ii) if you think the spec can be tweaked to be more explicit/clear.

I don't know what other browsers are doing (it might be especially interesting to see whether Safari delivers touch events to window2 while dragging over window1;  unfortunately I don't have a Mac with a touch screen).

#7 quoted a part of the HTML standard. Drag and Drop is covered by https://html.spec.whatwg.org/#dnd (section 6.7 of the current WHATWG spec [1]).

Input event suppression is covered in https://html.spec.whatwg.org/#drag-and-drop-processing-model (section 6.7.5). The text is rather long, and this is the key phrase: "From the moment that the user agent is to initiate the drag-and-drop operation, until the end of the drag-and-drop operation, device input events (e.g. mouse and keyboard events) must be suppressed."

The DnD spec hasn't received a lot of care lately. So, assuming we care about this case (I'm not sure we do), I would suggest that we look at what all other browsers do, and figure out how to align behaviors. We'd then update the spec to reflect the current reality or the behavior that we'd want to evolve to.

Given the prevalence of Windows, I expect that we'll either decide that input suppression is an implementation-dependent aspect (and remove it from the spec), or that we'll strengthen the spec to match exactly what happens on Windows. (I assume that input is blocked on both the source and the target tab?)

bsittler@: You've listed yourself as owner, so marking the bug Assigned. If you don't want it (I'm not sure this warrants more than an investigation), please mark as Available and clear the Owner field. 

I'm not convinced we need to specify this any more clearly right now, and I'm not convinced the current behavior variations matter much. Are there actual sites adversely affected by the behavior differences?

RE: Are there actual sites adversely affected by the behavior differences?

I am not aware of such sites - I've opened this bug only based on code analysis.  Given this - I think it might be okay to resolve as WontFix for now (and reopen later if we discover any real cases where this matters).