With the new HTML5 drag and drop API, I found an issue: - if a div is draggable, the drag cannot start if it contains text. - If it is empty, we should first click on it (by pushing and releasing the mouse button), and then we can begin a drag. - If the div have the -moz-user-select:none;, all works as expected. Look at the given html page to see this behaviors.

This patch checks the draggable attribute within the mouse down for selection handling.

Comment on attachment 336138 [details] [diff] [review] allow dragging within a selection > // static > PRBool >+nsContentUtils::ContentIsDraggable(nsIContent* aContent) >+{ >+ nsCOMPtr<nsIDOMNSHTMLElement> htmlElement = do_QueryInterface(aContent); >+ if (htmlElement) { >+ PRBool draggable = PR_FALSE; >+ htmlElement->GetDraggable(&draggable); >+ if (draggable) >+ return PR_TRUE; >+ } >+ >+ // special handling for content area image and link dragging >+ return IsDraggableImage(aContent) || IsDraggableLink(aContent); >+} What if image or link has dragable="false", should this return PR_FALSE in that case? nsHTMLImageElement and nsHTMLAnchorElement have their own implementation for ::GetDraggable.

> What if image or link has dragable="false", should this return PR_FALSE in that > case? Such as: nsCOMPtr<nsIDOMNSHTMLElement> htmlElement = do_QueryInterface(aContent); if (htmlElement) { PRBool draggable = PR_FALSE; htmlElement->GetDraggable(&draggable); if (draggable) return PR_TRUE; if (aContent->AttrValueIs(kNameSpaceID_None, nsGkAtoms::draggable, nsGkAtoms::_false, eIgnoreCase) return PR_FALSE; } ?

Um, I wasn't CC'd to this bug - sorry didn't notice the comment. But yes, something like that if you can't find any better way.