Bug 19386 - drag of links with styled text drop as links with plain text
Summary: drag of links with styled text drop as links with plain text
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Ryosuke Niwa
URL:
Keywords:
Depends on: 19331
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-03 20:11 PDT by Jonathon Jongsma (jonner)
Modified: 2012-05-01 18:36 PDT (History)
10 users (show)

See Also:


Attachments
potential fix for link drag and drop in edit mode (4.23 KB, patch)
2008-06-03 20:15 PDT, Jonathon Jongsma (jonner)
no flags Details | Formatted Diff | Diff
test case (430 bytes, text/html)
2008-06-05 08:48 PDT, Jonathon Jongsma (jonner)
no flags Details
Add a test (3.21 KB, patch)
2012-04-30 22:16 PDT, Ryosuke Niwa
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathon Jongsma (jonner) 2008-06-03 20:11:18 PDT
+++ 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
Comment 1 Jonathon Jongsma (jonner) 2008-06-03 20:15:13 PDT
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.
Comment 2 Mark Rowe (bdash) 2008-06-03 20:34:32 PDT
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 Jonathon Jongsma (jonner) 2008-06-05 08:33:39 PDT
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 Jonathon Jongsma (jonner) 2008-06-05 08:48:49 PDT
Created attachment 21510 [details]
test case

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

Thanks!
Comment 12 WebKit Review Bot 2012-05-01 07:59:53 PDT
Comment on attachment 139582 [details]
Add a test

Clearing flags on attachment: 139582

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