Unordered list paste: doesn't work correctly in IE

[tba21cn]

I checked Ticket #428 IE problems created unordered list from pasted list, it is not exactly the same as this one.

I have the following code in FCKeditor.

<ul>
    <li>unordered list item 1</li>
    <li>unordered list item 2</li>
    <li>unordered list item 3</li>
    <li>unordered list item 4</li>
</ul>

1. In edit view, high light 2nd and 3rd list items, and do copy.
2. go to some place without any format, and do paste, I've got:

   <p>
   <li>unordered list item 2</li>
   <li>unordered list item 3</li>
   </p>
   

The <li> lost <ul>.

It doesn't happen in FireFox, it is an IE only issue.

[Frederico Caldeira Knabben]

Confirmed with IE6. Ok with FF2.

This one seams to be hard to fix, as it is a clipboard issue, usually handled by the browser itself. A deeper analysis is needed.

[tba21cn]

I made a work around about this, but I don't think it is the "right way" to make it work, but maybe help. It is: If command is "Paste", move cursor back 1 character, check parent name(or ancestor's name) is LI or not, if find 'LI', check this 'LI' has 'UL'/'OL' as parent or not, if not, create a new 'UL' element, insert in front of this 'LI', and append this 'LI' to the 'UL', and check 'UL' 's preceding-sibling 'LI', and append them to the 'UL'(loop).

Replying to fredck:

Confirmed with IE6. Ok with FF2.

This one seams to be hard to fix, as it is a clipboard issue, usually handled by the browser itself. A deeper analysis is needed.

[Jon Håvard Gundersen]

Any progress on this one? This bug really messes with our documents. Maybe the best thing is to add a check to the processing of the document, because we could get bad html from sources outside of the editor also.

We really don't want listelements to appear outside of a list.

[Jon Håvard Gundersen]

I've created a suggestion on how to use document processor to move any parentless list elements into a bullet list to prevent messy html.

Any feedback? This solution is maybe a bit heavy on large documents with long lists, but the speed seems ok with my manual testing at least.

List = FCKDocumentProcessor.AppendNew() ;
List.ProcessDocument = function( document )
{
	var LIs = document.getElementsByTagName("LI");
	var listParent = /^(?:UL|OL)$/i;
	
	for(var i = 0; i < LIs.length; i++){
		var el = LIs[i]; 
		var parent = el.parentNode;
		var siblings = new Array();
		
		//Collect all siblings
		do {
			siblings.push(el);
		} while( LIs[i + 1] && el.nextSibling == LIs[i + 1] && (el = LIs[++i]))
		
		var parentName = parent.tagName ? parent.tagName.toLowerCase() : "";
		
		//Locate elements without correct parents
		if(!listParent.test(parentName)){
	
			
			if(parentName == "body") parent = siblings[0].previousSibling;
			
			while(parent.parentNode && parent.parentNode.tagName && parent.parentNode.tagName.toLowerCase() != "body"){
				parent = parent.parentNode; 		
			}
			
			//Create new list
			var list = document.createElement("UL");
			for (var j = 0; j < siblings.length; j++){
				list.appendChild(siblings[j]);
			}
			
			if( parent ) document.body.insertBefore(list, parent);
			else FCK.InsertElement(list);
			
			
		}
	}
}

[Frederico Caldeira Knabben]

I was wondering if it would not be safer to make those checks in the XHTML processor, as it would guarantee that the output is correct, no matter the (unknown and strange) operation made in the editor. In this way, we would fix any possible problem related to orphan LIs.

Also, maybe the logic for the fix could be a little bit simpler, just checking for the parent node, and moving the node and it siblings when needed. Everything in a single loop.

[Jon Håvard Gundersen]

You're probably right. It had been fun if you explained a bit how the xhtml processor works. It isn't as easy as the document processor to understand :). I also think that we need to be sure that the xhtml processor is runned immediately after paste and not only when switching view mode or saving.

In general I think that it is a bit confusing for the user when the document could be changed after he saves it. This should happen in real time - thats why I went for the document processor.

[Jon Håvard Gundersen]

And the point of the nested loop is to prevent checking parent on all siblings :) Note the iterator value is ascending.

[Martin Kou]

Tidied up the description a bit.