Bug 13033

Summary: Copying/pasting links adds unnecessary styles
Product: WebKit Reporter: webkit
Component: HTML EditingAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: enrica, eric, justin.garcia, michael.vm, rniwa
Priority: P2    
Version: 523.x (Safari 3)   
Hardware: PC   
OS: OS X 10.4   
URL: http://www.fckeditor.net/nightly/browsers_test.html
Bug Depends on:    
Bug Blocks: 9915    

webkit
Reported 2007-03-10 05:50:16 PST
When dragging a linked text, the following attribute is appended to the <a> element: --- style="color: rgb(0, 0, 255) -webkit-text-decorations-in-effect: underline; " --- 1. Open the FCKeditor test page in the provided URL; 2. Select the text "using FCKeditor."; 3. Drag it to somewhere else in the text; 4. Switch to Source view to see the results.
Attachments
Justin Garcia
Comment 1 2007-03-12 14:31:55 PDT
The styles don't effect correctness in the editor. They could conceivably effect correctness in an editor that let the user adjust the default link style.
webkit
Comment 2 2007-06-12 03:20:28 PDT
Update on this: There was some changes on the resulting style addition. The nightly and Safari 3 Beta now adds the following to the <a>: --- style="color: rgb(0, 0, 255) !important; " --- It doesn't happen to Safari 3 for Windows, so it seams to be OS dependent.
webkit
Comment 3 2007-09-29 09:20:51 PDT
More info... it happens only when selecting "text + link", like "You are using <a href="http://www.fckeditor.net">FCKeditor</a>.". If you double click the link, it is dragged as an object instead, and no styles are appended to it.
webkit
Comment 4 2007-09-29 09:27:19 PDT
(In reply to comment #1) > The styles don't effect correctness in the editor. They could conceivably > effect correctness in an editor that let the user adjust the default link > style. It is not a matter of presentation inside the editor. Actually nobody would be using an editor to read things. The problem here Justin is that the editor is used to produce content, which will be used somewhere else. Then, we have two issues: - Developers, which will be unhappy to have the editor producing unneeded HTML. They get really disappointed with such things; - Incorrect link styles when placing the contents inside a page (the common case). The page could (and usually) have styles completely different from those used inside the editor. Also, the same content can be targeted to different pages or even sites, with style completely different.
Eric Seidel (no email)
Comment 5 2007-11-22 11:40:26 PST
I agree this is a bug, not sure why the current behavior exists as it does. Probably to maintain good color fidelity when copying/pasting between a site and a mail message for instance. We'd need to understand why the current behavior exists before we could come up with a solution.
webkit
Comment 6 2007-11-23 02:05:39 PST
(In reply to comment #5) > I agree this is a bug, not sure why the current behavior exists as it does. > Probably to maintain good color fidelity when copying/pasting between a site > and a mail message for instance. That's the conclusion I had too. But it assumes that the content will always be used inside a non-styled page. There are two things that could be considered here to solve it: - Copy the link as is if the source is the same document as the target. I mean, if I copy and paste a link inside the same FCKeditor document, I should not have changes to it. - Implement a way to configure it. Maybe something similar to Firefox's execCommand('styleWithCSS',true|false,null). In this way we instruct WebKit on whether maintaining the link color on pasting, or leaving it intact. Maybe a generic thing like execCommand('autoCorrect',true|false,null) would be even better, if WebKit is doing also other things automatically, not limited to the link color thing.
Ryosuke Niwa
Comment 7 2010-08-19 18:14:31 PDT
I believe this bug has been fixed now because of my fixes in ApplyStyleCommand and various other parts of editing code.
Ryosuke Niwa
Comment 8 2010-08-24 12:14:44 PDT
Closing the bug because the described behavior is no longer present on TOT.
Note You need to log in before you can comment on or make changes to this bug.