|Summary:||drag of links with styled text drop as links with plain text|
|Product:||WebKit||Reporter:||Jonathon Jongsma (jonner) <jonathon>|
|Component:||HTML Editing||Assignee:||Ryosuke Niwa <rniwa>|
|Severity:||Normal||CC:||darin, dbates, dcheng, enrica, justin.garcia, mrobinson, oliver, rniwa, simon.fraser, webkit.review.bot|
|Version:||528+ (Nightly build)|
|Bug Depends on:||19331|
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 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 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 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.