Opened 13 years ago
Closed 12 years ago
#7957 closed Bug (fixed)
Bulleted list and copy/paste problems
Reported by: | oiha | Owned by: | Garry Yao |
---|---|---|---|
Priority: | Normal | Milestone: | CKEditor 4.0 |
Component: | Core : Lists | Version: | 3.0 |
Keywords: | IBM | Cc: | damian.chojna@…, satya_minnekanti@…, monahant@… |
Description
Note: This problem may relate to lists in general.
Users complain that bulleted lists cannot be rearranged without much hazzle. The WYSIWYG representation does not always lead the users to correct actions.
Example 1: Create a bulleted list of three or more entries in an empty page. (The code should start with UL-tag directly.) Copy the second list entry and insert it at start of the first list entry. Object of the exercise is to rearrange list entries, but result is that a new UL-tag is inserted at the very start of the LI-tag. Original bullet becomes hidden, and the fun starts when the user mistakenly tries to reintroduce that bullet.
Example 2: Create a list similar to the list in example 1 and in addition make the first entry underlined. Repeat action as described in example 1 and witness the indented and underlined copied list entry - and as an extra bonus the missing bullet from example 1. The users are still not amused.
I cannot understand that inserting a LI-tag with content at the very start of another LI-tag can be interpreted as anything else than rearranging the list. Introducing other tags can hide the matter, but CKEditor is a text editor and not a code editor, right?
I believe this problem was reported long time ago for FCKEditor, but I cannot find the ticket... I also believe it was fixed...
Attachments (6)
Change History (20)
comment:1 Changed 13 years ago by
comment:2 Changed 13 years ago by
Keywords: | W7/XP IE8 removed |
---|---|
Status: | new → confirmed |
Version: | 3.6 → 3.0 |
- Copy the below code:
<ul> <li> dd</li> <li> ddd</li> <li> dddd</li> </ul>
- Select ddd with mouse or keyboard and press CRTL+X.
- Place the cursor before "dd" and press CRTL+V
It seems it has never worked correctly in Opera, Webkit, IE8 and FireFox (See screentshots of the results I've got)
In IE6, IE7 and IE7 rearranging lists worked till version 3.5.2. For 3.5.3 and above see screenshots.
Till version 3.5.2 IE8 behaved almost correctly. Pasting worked but cutting out element always resulted in empty element left behind.
Changed 13 years ago by
Attachment: | Webkit.png added |
---|
Changed 13 years ago by
Changed 13 years ago by
Changed 13 years ago by
Changed 13 years ago by
Changed 13 years ago by
comment:4 Changed 12 years ago by
Cc: | damian.chojna@… added |
---|---|
Keywords: | IBM added |
Customer just reported this.
comment:5 Changed 12 years ago by
Cc: | satya_minnekanti@… added |
---|
comment:6 Changed 12 years ago by
Cc: | monahant@… added |
---|
comment:7 Changed 12 years ago by
Milestone: | → CKEditor 4.0 |
---|
The Firefox behavior is the most closest one so far, considering that we don't manage HTML insertion in v3 (it's the browser behavior to not to insert just the list items), v4 is probably the right place to land a fix for such issue.
comment:8 Changed 12 years ago by
I was investigating this issue while working on v4's implementation of insertHtml and clipboard handling. Usually the biggest problem is that identically looking selections may result in different content in clipboard. Even testing on only one browser.
- E.g. on Firefox:
"aaa"
or"<ul><li>aaa<br></li><li></li></ul>"
. - On IE8:
"aaa"
or"<LI>aaa</LI>"
. - On Chrome:
"aaa"
or"<ul><li>aaa</li><li></li></ul>"
(in fact on Webkits the second one looks differently, because the EOL is selected).
You can check that on /plugins/clipboard/samples/clipboard.html
The "aaa"
doesn't give us any clue that list item was copied, so it will be inserted as inline content.
However, second versions we can handle in different way. On Webkits and Firefox we're even sure that EOL was (visually - on Webkits only) selected, so cursor may be put at the beginning of the next list item.
comment:9 Changed 12 years ago by
I am really pleased that this problem is considered for version 4.
I have downloaded the v4 beta, and have tested my initial problem. It seems that v4 beta is working differently than v3.6 much in the way Reinmar is discussing.
- I created a bulleted list of four elements. I can now (mostly) copy a single bullet and paste it at the start of any other bullet, even if that bullet content is underlined. To finish the operation and get the right result I need to hit ENTER.
- In some rare cases the initial problem reoccur, and then I am stuck with it.
- Copying 2 or more bullets give the initial problem every time, and of course it does not matter where you paste - either first bullet or later in the list.
I believe we could live with the first result, as this can be understood and corrected by the user in an orderly manner.
Thank you.
comment:10 Changed 12 years ago by
Owner: | set to Piotrek Koszuliński |
---|---|
Status: | confirmed → assigned |
Regarding current implementation, as I said, we've rewritten insertHtml implementation, but haven't got enough time before Beta to finish all cases, so lists handling has a fallback to native impls. Thus, it behaves differently, because in some cases we're handling insertion and in other leave it for the browser.
Anyway, full insertion impl is part of v4, so... stay tuned :D
comment:11 Changed 12 years ago by
Owner: | changed from Piotrek Koszuliński to Garry Yao |
---|
comment:12 Changed 12 years ago by
Status: | assigned → review |
---|
Opened branch t/7957 on both dev and test for review, it replicates the native behavior of FF/Webkit, when list items are inserted at the start/end of an existing list item, into separated items.
Note that the fix is assuming the list structure found inside of clipboard data, so it will not result in anything different for copying and paste a single list item, which actually copied only the item content, this TC is only considerable in the future when we have fully managing the copied content.
comment:13 Changed 12 years ago by
Rebased both branches to current master.
I removed commit 305b4031@tests which looks like some unrelated mistakenly done commit introducing red test.
comment:14 Changed 12 years ago by
Resolution: | → fixed |
---|---|
Status: | review → closed |
Masterised. Kudos, Garry.
https://github.com/ckeditor/ckeditor-dev/commit/7e1b04b8c876bae39dac67ee742c45123aac103a
This problem was not present in FCKEditor 2.6.5