Opened 8 years ago

Last modified 8 years ago

#14765 confirmed Bug

Copying from IE divarea editor to Chrome/Firefox in results in full nodes path.

Reported by: Jakub Ś Owned by:
Priority: Normal Milestone:
Component: General Version: 4.5.0
Keywords: IBM Cc: satya_minnekanti@…

Description (last modified by Jakub Ś)

Steps to reproduce

  1. Open any sample page say api.html in Chrome and set pasteFilter config to null and allowedContent to true.
    CKEDITOR.replace( 'editor1', {
    	allowedContent : true,
    	pasteFilter : null,
    ...
    
  2. Open http://ckeditor.com/demo#div in IE browser and copy two paragraphs
  3. Paste the content in api.html page which is opened in chrome and go to Source mode

Expected result

Only two paragraphs get pasted.

Actual result

It looks like paragraph plus every node above/below also get pasted.

Other details (browser, OS, CKEditor version, installed plugins)

This is a special case where you need to disable pasteFilter to get this result. User who reported it, does some paste filtering on his own but he can't really do much in this case as he doesn't know what the original selection from other browser was.

This doesn't happen in native contenteditable thus I have decided to report it.

Problem can be reproduced when copying from IE and pasting into Chrome or Firefox.

Attachments (2)

result.png (33.7 KB) - added by Jakub Ś 8 years ago.
result2.png (54.7 KB) - added by Jakub Ś 8 years ago.

Download all attachments as: .zip

Change History (6)

comment:1 Changed 8 years ago by Jakub Ś

Description: modified (diff)
Status: newconfirmed

Changed 8 years ago by Jakub Ś

Attachment: result.png added

Changed 8 years ago by Jakub Ś

Attachment: result2.png added

comment:2 Changed 8 years ago by Marek Lewandowski

The problem here is that new clipboard API introduced in 4.5.0 skips <!--StartFragment--> markers, which in this particular example plays an important role, because IE is giving whole context (parent elements) to the clipboard, and marks actual selection with <!--StartFragment-->.

My git blame has shown that initial reason for this decision was to fix pasting from apps like MS Excel, which put <!--StartFragment--> markers in a wrong place, e.g. inside the table like so:

<body link="#0563C1" vlink="#954F72">

<table border=0 cellpadding=0 cellspacing=0 width=128 style='border-collapse:
 collapse;width:96pt'>
<!--StartFragment-->
 <col width=64 span=2 style='width:48pt'>
 <tr height=20 style='height:15.0pt'>
  <td height=20 align=right width=64 style='height:15.0pt;width:48pt'>11</td>
  <td align=right width=64 style='width:48pt'>22</td>
 </tr>
 <tr height=20 style='height:15.0pt'>
  <td height=20 style='height:15.0pt'>aa</td>
  <td class=xl65>bb</td>
 </tr>
 <tr height=20 style='height:15.0pt'>
  <td height=20 style='height:15.0pt'>AA</td>
  <td>BB</td>
 </tr>
<!--EndFragment-->
</table>

</body>

Fixing this problem would require a more time, to ensure we do not fall for regressions.

comment:3 Changed 8 years ago by Satya Minnekanti

Cc: satya_minnekanti@… added

comment:4 Changed 8 years ago by Satya Minnekanti

Keywords: IBM added
Note: See TracTickets for help on using tickets.
© 2003 – 2022, CKSource sp. z o.o. sp.k. All rights reserved. | Terms of use | Privacy policy