|Summary:||drag of links with styled text drop as links with plain text|
|Product:||WebKit||Reporter:||Jonathon Jongsma (jonner) <firstname.lastname@example.org>|
|Component:||HTML Editing||Assignee:||Ryosuke Niwa <email@example.com>|
|Severity:||Normal||CC:||firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com|
|Version:||528+ (Nightly build)|
|Bug Depends on:||19331|
+++ This bug was initially created as a clone of Bug #19385 +++ Steps to reproduce: - make page editable - click on and drag a link - drop the link in a different spot on the page (e.g. in the middle of a paragraph somewhere) results: - the link is deleted from its original position, but it is not inserted correctly into the document at the new position expected behavior: - the link should be moved from the old position to the new drop position
Created an attachment (id=21490) [details] potential fix for link drag and drop in edit mode Basically, when dragging a link WebKit was saving the Link URL to the clipboard, we should also store the html fragment as an alternate format for when we drop the link into an editable html document.
This already behaves correctly on the Mac, which suggests to me that the fix should not be in core cross-platform code but in GTK-specific client classes.
Strange, I don't see how this can work properly in mac webkit. From my understanding of the source, when you start a link drag (DragController::startDrag()), if the item being dragged is a link, it saves the URL and the link text to the dragging clipboard (using clipboard->writeURL()). This is enough information if you're just dragging it to an external application or to the address bar or something like that. But if you're trying to drop it into an html document, you'll need the full html representation in the clipboard. For example, consider the following html fragment: <a href="http://foo.com" title="title text" target="_blank" style="color:orange">my link</a> As far as I can tell, when you drag this link currently, the only pieces of information that get saved to the dragging clipboard are "http://foo.com" and "my link". So if I now drop this into an editable html document, It seems like I'll only get the following html fragment: <a href="http://foo.com">my link</a> This is essentially the behavior I see in QtWebKit. So we just lost a lot of information about this element in the process of dragging and dropping it. I examined the code for mac and I unless I'm missing something it seems that it should behave the same as Qt in this case. Can you check this? Note that the behavior may depend on whether any text is selected or not when you start the drag (see bug #19331)
Created an attachment (id=21510) [details] test case A simple html document with some links with various attributes and formatting to test dragging.
I can confirm that the bug demonstrated in the above test case manifests on the Mac as well. The test case could be improved so that it has an editable div inside it that we can drag to instead to instead of having to open a separate designMode document.
(From update of attachment 21490 [details]) Assigning oliver as a specific reviewer. Oliver, if you believe someone else should review this in your stead, please assign it to them.
(From update of attachment 21490 [details]) I am not convinced that the patch is correct. Arguably in content editable mode when you select the text of a link and drag it it should behave identically to dragging iny other text that may be dragged. There's also no reason this should not have an automated test attached as it is a simple single doc drag test.
It seems like this bug has been fixed already.
Created an attachment (id=139582) [details] Add a test
I confirmed this test passes on GTK+ as well.
(In reply to comment #10) > I confirmed this test passes on GTK+ as well. Thanks!
(From update of attachment 139582 [details]) Clearing flags on attachment: 139582 Committed r115724: <http://trac.webkit.org/changeset/115724>
All reviewed patches have been landed. Closing bug.