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.
Thanks for filing this. Will be thrilled to see these bugs fixed.
What is the status of this list? Does someone believe that these are all bugs (per whatever spec), or are these just implementation notes for Opera?
Some are definitely bugs: - Drop handler preventing navigation even if default not prevented. - "Text" and "URL" present in DataTransfer.types. Some are areas where we currently don't match the spec: - dropEffect defaults - drag/dragover events fired too quickly - drop allowed even if dragenter not cancelled (the spec says you have to cancel both dragenter and dragover) Some are intentional from what I recall: - FileReader not opening files when the page is loaded from a file:// URL.
> Some are intentional from what I recall: > - FileReader not opening files when the page is loaded from a file:// URL. Actually, that's wrong, tracked as bug 78648.
(In reply to comment #3) > Some are definitely bugs: > - Drop handler preventing navigation even if default not prevented. Drop a URL on IE6/7/8, the browser navs. Drop a URL in IE6/7/8 on a <div> that cancels the default action of dragenter/dragover, the browser _does not_ nav. Same results for a File. The spec is based on IE6; Opera and Firefox are out of spec.
(In reply to comment #5) > (In reply to comment #3) > > Some are definitely bugs: > > - Drop handler preventing navigation even if default not prevented. > > Drop a URL on IE6/7/8, the browser navs. Drop a URL in IE6/7/8 on a <div> that cancels the default action of dragenter/dragover, the browser _does not_ nav. Same results for a File. The spec is based on IE6; Opera and Firefox are out of spec. I'll ask for clarification. However, the original IE drag and drop event model is... quirky to say the least. It does not seem intuitive that merely canceling the dragenter/dragover events should be enough to prevent the default action of a *drop*. Given that the original IE model was meant to deal with text and URLs, I think we have some flexibility for improving this.
(In reply to comment #6) > I'll ask for clarification. However, the original IE drag and drop event model is... quirky to say the least. It does not seem intuitive that merely canceling the dragenter/dragover events should be enough to prevent the default action of a *drop*. Given that the original IE model was meant to deal with text and URLs, I think we have some flexibility for improving this. The original IE model defined dataTransfer.getData(Text|URL|Image|HTML|File). Quirky and unintuitive is perhaps a matter of opinion; I think it has never been better stated than this [1] ... "You must cancel the default action for ondragenter and ondragover in order for ondrop to fire. In the case of a div, the default action is not to drop. This can be contrasted with the case of an input type=text element, where the default action is to drop. In order to allow a drag-and-drop action on a div, you must cancel the default action by specifying window.event.returnValue=false in both the ondragenter and ondragover event handlers. Only then will ondrop fire." [1] http://msdn.microsoft.com/en-us/library/ms536929(v=vs.85).aspx