[Webkit-unassigned] [Bug 79171] New: Metabug for drag and drop issues found by Opera

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=79171

           Summary: Metabug for drag and drop issues found by Opera
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Unspecified
        OS/Version: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Platform
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: dcheng at chromium.org
                CC: tony at chromium.org, abarth at webkit.org, rniwa at webkit.org
        Depends on: 37012


I don't think all of these will be fixed, but we should look at the list of issues at least. I'm filing this bug so they don't get lost though.

=EffectAllowed and dropEffect=

* Firefox and Chrome use the wrong defaults for dropEffect - move instead of copy for dragging a div, when the effectAllowed is "all" or "uninitialized".

* Firefox allows the user to choose "copy" instead of "move" by pressing Ctrl. Chrome doesn't allow any modifiers, neither does IE. Opera allows platform integration to decide; gogi implementation uses normal platform modifier keys for copy/move/link.

* Chrome always gives "none" for implicit dropEffect.

* Chrome makes dropEffect readonly in most cases.

* Firefox chooses to reinitialise dropEffect in dragend to have the same value it had at the start of drop. Opera and Chrome choose to be consistent, and accept the last value it had - this is unspecified per spec, but similar to the specified part about cancelling drags: "set the current drag operation to the value of the dropEffect attribute of the DragEvent object's dataTransfer object as it stood after the event dispatch finished".

=Dragging inputs and interactive elements=

* We have decided to make certain interactive elements be "special", for compatibility with other browsers, and user expectations. This is not covered by the spec. A page is highly unlikely to make an editable element be draggable but it's quite possible to have an input somewhere inside a draggable element. The user still wants to be able to select text in that element and interact normally with it.
 * Input/select/textarea/button cannot be dragged.
 * ContentEditable elements cannot be dragged.
 * Editable SVG elements cannot be dragged.
 * Scrollbars must respond as scrollbars, not draggable points.

* Chrome breaks contentEditable when it can be dragged; you cannot drag by the text of a contentEditable element (only the border), and you cannot edit it either.

* Firefox allows dragging of a contentEditable element inside a draggable element, but not when the contentEditable element itself is draggable - inconsistent and probably a bug in the former case.

* Chrome allows you to drag a select-multiple by its border

* Chrome allows buttons to be drag points, Firefox does not. Easier to be consistent with all inputs.

* Chrome may randomly allow a readonly input element to be draggable by its border - not always reproducible bug.

=Dragging files into the browser=

* In Opera and FF, you have to preventDefault on the drop event, or the browser will correctly open the file *after* handing it to the page. In Chrome, simply having a drop listener is enough to prevent it opening the file, which is not spec-compliant.

* Chrome refuses to use the FileReader to load files when the page is loaded over file:

* Dragging a folder instead of a file;
 * FF manages to load the "file" even though it cannot have contents, Chrome
   and Opera produce a 0 byte file (or file with size depending on platform)
   which immediately fires onerror.
 * Chrome and Opera both refuse to drop special folders (depends on platform).
 * Chrome drops 0 files when you drop "my documents".

* Firefox and Chrome do nothing if the dropEffect is set to "none". Opera reverts to default behaviour, which is to open files.

=Other problems=

* Chrome does not support addElement

* Firefox and Chrome repeatedly fire drag and dragover a lot faster than they should - 16 times per second.

* Firefox and Chrome both fail to work with dropzone

* Firefox and Chrome both allow dropping even if you fail to cancel dragenter - you only have to cancel dragover (this also means that dragenter does not fire on body if another element fails to cancel its own dragenter). This can be seen in some online demos (eg.  <http://html5demos.com/drag>), which correctly cancel it for IE.

* Firefox and Chrome both fail to fire body.ondragenter a second time when it does not cancel ondragenter, and drag moves from div-as-current-target onto body

* Firefox and Chrome do not convert from "url" to "text/uri-list" with getData. Chrome seems to assume both are always empty when they are manually set. Firefox and Opera strip whitespace as expected for 'url', and Firefox also mistakenly strips fragments. Firefox incorrectly acts as if convert-to-URL were true when using "text/uri-list".

* In a document with no elements, Chrome makes the document object be the current target. Opera and Firefox make it null.

* Chrome adds separate entries for "text", "text/plain", "url" and "text/uri-list" into the .types collection.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.