Bug 19386

Summary: drag of links with styled text drop as links with plain text
Product: WebKit Reporter: Jonathon Jongsma (jonner) <jonathon@quotidian.org>
Component: HTML EditingAssignee: Ryosuke Niwa <rniwa@webkit.org>
Severity: Normal CC: darin@apple.com, dbates@webkit.org, dcheng@chromium.org, enrica@apple.com, justin.garcia@apple.com, mrobinson@webkit.org, oliver@apple.com, rniwa@webkit.org, simon.fraser@apple.com, webkit.review.bot@gmail.com
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
Bug Depends on: 19331    
Bug Blocks:    
Description Flags
potential fix for link drag and drop in edit mode
test case
Add a test none

Description From 2008-06-03 20:11:18 PST
+++ 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)

- 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
------- Comment #1 From 2008-06-03 20:15:13 PST -------
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.
------- Comment #2 From 2008-06-03 20:34:32 PST -------
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.
------- Comment #3 From 2008-06-05 08:33:39 PST -------
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)
------- Comment #4 From 2008-06-05 08:48:49 PST -------
Created an attachment (id=21510) [details]
test case

A simple html document with some links with various attributes and formatting to test dragging.
------- Comment #5 From 2008-07-27 19:03:04 PST -------
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.
------- Comment #6 From 2008-08-01 12:17:54 PST -------
(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.
------- Comment #7 From 2008-08-02 23:16:36 PST -------
(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.
------- Comment #8 From 2012-04-30 21:37:14 PST -------
It seems like this bug has been fixed already.
------- Comment #9 From 2012-04-30 22:16:39 PST -------
Created an attachment (id=139582) [details]
Add a test
------- Comment #10 From 2012-04-30 23:39:14 PST -------
I confirmed this test passes on GTK+ as well.
------- Comment #11 From 2012-05-01 00:08:45 PST -------
(In reply to comment #10)
> I confirmed this test passes on GTK+ as well.

------- Comment #12 From 2012-05-01 07:59:53 PST -------
(From update of attachment 139582 [details])
Clearing flags on attachment: 139582

Committed r115724: <http://trac.webkit.org/changeset/115724>
------- Comment #13 From 2012-05-01 08:00:12 PST -------
All reviewed patches have been landed.  Closing bug.
------- Comment #14 From 2012-05-01 18:36:33 PST -------
Skipped the test on Qt & WK2 in http://trac.webkit.org/changeset/115777 & http://trac.webkit.org/changeset/115778.