Bug 19386 – drag of links with styled text drop as links with plain text

• Status: RESOLVED
• Resolution: FIXED
• Component: HTML Editing

[Jonathon Jongsma (jonner)]

+++ 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

[Jonathon Jongsma (jonner)]

Created attachment 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.

[Mark Rowe (bdash)]

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.

[Jonathon Jongsma (jonner)]

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)

[Jonathon Jongsma (jonner)]

Created attachment 21510 [details]
test case

A simple html document with some links with various attributes and formatting to test dragging.

[Eric Seidel (no email)]

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.

[Eric Seidel (no email)]

Comment on attachment 21490 [details]
potential fix for link drag and drop in edit mode

Assigning oliver as a specific reviewer.  Oliver, if you believe someone else should review this in your stead, please assign it to them.

[Oliver Hunt]

Comment on attachment 21490 [details]
potential fix for link drag and drop in edit mode

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.

[Ryosuke Niwa]

It seems like this bug has been fixed already.

[Ryosuke Niwa]

Created attachment 139582 [details]
Add a test

[Martin Robinson]

I confirmed this test passes on GTK+ as well.

[Ryosuke Niwa]

(In reply to comment #10)
> I confirmed this test passes on GTK+ as well.

Thanks!

[WebKit Review Bot]

Comment on attachment 139582 [details]
Add a test

Clearing flags on attachment: 139582

Committed r115724: <http://trac.webkit.org/changeset/115724>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.

[Ryosuke Niwa]

Skipped the test on Qt & WK2 in http://trac.webkit.org/changeset/115777 & http://trac.webkit.org/changeset/115778.