[IE] enterKey incorrect with list item

[Garry Yao]

Reproducing Procedures

1. Open the replace by code example page;
2. Make document content and selection as following:

   <ol>
   	<li>
   		level1^
   		<ol>
   			<li>
   				level2</li>
   		</ol>
   	</li>
   </ol>
   

3. Press Enter key

• Actual Result :

  <ol>
  	<li>
  	</li>
  	<li>
  		level1
  		<ol>
  			<li>
  				level2</li>
  		</ol>
  	</li>
  </ol>
  

• Expected Result :

  <ol>
  	<li>
  		level1
  		<ol>
  			<li>
  				level2</li>
  		</ol>
  	</li>
  	<li>
  	</li>
  </ol>
  

[Frederico Caldeira Knabben]

Confirmed with IE.

I'm having the expected result specified in the ticket with FF, but the correct result should be instead:

<ol>
	<li>
		level1</li>
	<li>
		^
		<ol>
			<li>
				level2</li>
		</ol>
	</li>
</ol>

[Garry Yao]

Replying to fredck: I've go the result you expected with current trunk in FF, but when comparing to MS-Word, it would give result as below, which seems to be more reasonable.

<ol>
	<li>
		level1
	</li>
	<li>^
	</li>
	<li>
		<ol>
			<li>
				level2</li>
		</ol>
	</li>	
</ol>

[Frederico Caldeira Knabben]

Replying to garry.yao:

which seems to be more reasonable.

No, it's not. A text empty <li> can easily become a selection pain for us.

[Garry Yao]

#4009 has been marked as DUP.

[Garry Yao]

Ticket Test added at :
​http://ckeditor.t/tt/3165/1.html.

[Garry Yao]

The way that v2 used to work around this situation is wrong (#1420) where a NBSP is used as line holder, for the following reasons:

1. Break keyboard navigation;
2. Break reversibility: if user press 'Backspace' after he pressed 'Enter', the result is not guaranteed and since we don't have managed backspace keystroke (at least for now), it sucks.
   

[Frederico Caldeira Knabben]

IE8 issue after 3165.patch

[Frederico Caldeira Knabben]

Things look better after the patch, but the <br> trick has its drawback:

• In FF, the addition <br> remains there. It may not be an issue with the enter code, but it should be cleaned up on output.

• In IE, the most important issue. Check out the attached screenshot. The <br> generates some unwanted space in the list. Even worst, if you continue hitting ENTER and adding text, the number of <br>s increase and the space gets bigger.

So, much probably, the solution used to fill paragraphs must be the same to be used here.

[Garry Yao]

As discussed with Fred today:

In FF, the addition <br> remains there. ...it should be cleaned up on output.

FF works well with <br> as filler in wysiwyg, while filler node in output should always be &nbsp;

In IE, ...The <br> generates some unwanted space in the list.

<br> is quite broken in IE8, though works in IE6/7, we would keep using the NBSP for IE only, even though the backspace logic is still buggy.

[Frederico Caldeira Knabben]

• In Firefox, the <br> is still there if we type some text after hitting enter:

<ol>
	<li>
		level1</li>
	<li>
		Some text<br />
		<ol>
			<li>
				level2</li>
		</ol>
	</li>
</ol>

• We have the same issue with IE, but instead of a <br> we have a &nbsp;:

<ol>
	<li>
		level1</li>
	<li>
		Some text&nbsp;
		<ol>
			<li>
				level2</li>
		</ol>
	</li>
</ol>

Even worst, if you continually hit ENTER and type text for each new item, the last one will accumulate lots of &nbsp;, one for each ENTER.

In all browsers we should have the &nbsp; only if the list remains empty, like the following:

<ol>
	<li>
		level1</li>
	<li>
		&nbsp;
		<ol>
			<li>
				level2</li>
		</ol>
	</li>
</ol>

[Garry Yao]

The new patch is targeting the above mentioned issue.
Noted that the changes within the selection plugin is to make sure that only one NBSP is to be introduced at this point.

[Frederico Caldeira Knabben]

Ok for the changes, but is it possible to have the filtering thing in the list plugin? The data processor is really becoming a mess.

[Garry Yao]

Fixed with [4546].