Opened 9 years ago

Closed 9 years ago

Last modified 8 years ago

#12024 closed defect (fixed)

WebKit: Editor copy and paste causes an extra div in the editor and changes the text display

Reported by: Katie Vance Owned by:
Priority: high Milestone: 1.6
Component: Editor Version: 1.5
Keywords: Cc:
Blocked By: Blocking:

Description

In Safari or chrome, if you copy and paste something from the editor to the same editor, then the text style changes because an extra div is place around the text value.

After copying and pasting "testingCopyAndPaste" a couple of times this is the value I am getting from editor.getValue:

<div style="background-image: initial; background-attachment: initial; background-origin: initial; background-clip: initial; background-color: transparent; padding-top: 1px; padding-right: 0px; padding-bottom: 0px; padding-left: 0px; margin-top: -1px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; width: 100%; height: 100%; top: 0px; left: 0px; right: 0px; font: normal normal normal 11px/normal Verdana, Arial, Helvetica, sans-serif; min-height: 1em; line-height: normal; overflow-x: auto; overflow-y: auto; color: rgb(19, 19, 19); font-family: 'Times New Roman'; font-size: medium; ">testingCopyAndPastetestingCopyAndPastetestingCopyAndPaste</div><div></div>

I would expect the div not to be there, only the text.

This is causing the EnterKeyHandling? plugin to not work as expected in webkit browsers as well. For that reason, the copy and paste tests for EnterKeyHandling? will be commented out until this is resolved.

Change History (12)

comment:1 Changed 9 years ago by Jared Jurkiewicz

I think the way you're automating the tests is causing this. You're selecting the entire node, not the text content, so you're getting all the node styles of the editor frame.

comment:2 Changed 9 years ago by Katie Vance

It is selecting the entire node, however, it's not a problem with the automated test. You can manually reproduce the issue with test_Editor by entering text, selecting all (either by ctrl-a or by highlighting evertyhing), and then pasting. You may not see the problem if you only select a portion of the visible text.

comment:3 Changed 9 years ago by Jared Jurkiewicz

It has to do with the entire node being the <body> tag. It's somehow grabbing all the applied styles too. If you do in WebKit? like done in IE (Use an internal DIV, there's a cople sections in RichText?.js that handle deciding if it's body, or body.firstChild), it doesn't do that. But that causes the automated EnterKeyHandling? tests to fail.

comment:4 Changed 9 years ago by Jared Jurkiewicz

(In [23385]) Trying to fix the copy/paste issue in webkit by using the nested div to isolate it from accidentally picking up body styles in copy. \!strict #refs #12024

comment:5 Changed 9 years ago by Jared Jurkiewicz

(In [23386]) Tweaking test. \!strict #refs #12024

comment:6 Changed 9 years ago by Jared Jurkiewicz

(In [23387]) Tweaking test. \!strict #refs #12024

comment:7 Changed 9 years ago by Jared Jurkiewicz

(In [23388]) Tweaking test. \!strict #refs #12024

comment:8 Changed 9 years ago by Jared Jurkiewicz

(In [23389]) Tweaking test. \!strict #refs #12024

comment:9 Changed 9 years ago by Jared Jurkiewicz

(In [23390]) Tweaking test. \!strict #refs #12024

comment:10 Changed 9 years ago by Jared Jurkiewicz

(In [23391]) Tweaking test. \!strict #refs #12024

comment:11 Changed 9 years ago by Jared Jurkiewicz

Milestone: tbd1.6
Resolution: fixed
Status: newclosed

comment:12 Changed 8 years ago by bill

In [26205]:

webkit no longer needs a special branch in the test file. refs #12024. tested on safari 5.1/mac, safari 5.1/win and chrome 14/win

Note: See TracTickets for help on using tickets.