Edit area adding <p> when clicking in the edit area

[Damian]

To reproduce:

1. Open nightly sample
   
2. Add a table with default settings
   
3. Click in the editing area, next to the table (to the right of the table in LTR mode)
   

Results in a new <p> being added to the document. The document grows with every subsequent click.

<p>
	&nbsp;</p>

Reproduced on IE 6 and 7.

[Garry Yao]

This's supposed to be fixed with #3657.

[Garry Yao]

This has been proven to be out the range of #3657.
After some investigation, this's been caused by a feature from IE and Webkit:

1. If 'mousedown' event is beside the table, move the selection right following the table;
2. If 'Arrow Key' keypress event is happened at the last table cell editing position, move the selection out same as 1.

Which will result in a rare selection as:

<table>...</table>^

Now that our 'auto fixing block-less logic' commit a crime by "fixing" this into:

<table>...</table><p>^</p> // A new paragraph is established.

[Garry Yao]

After talking with Fred, we found that not only happen for <table> and even happen for FF, reproduce with:

1. Load the editor with:

   <hr />
   

2. Click on the spaces around top margin of this hr;

• Result: New line appended.

[Garry Yao]

We already know that the fixBody functionality is for good of guarantee user could always type inside a enter block(p,div) , so if we found such a selection, it indicate that user is trying to exit from some block( maybe table, pre, hr ), so now we should not fix immediately, instead, we're checking whether there's already a 'enter block' around, if found, we'll simply moving into that paragraph, so user could continue to type inside it OR user could press enter now for new paragraph if he want.

[Frederico Caldeira Knabben]

The proposed patch is not handling collapsed selections inside text nodes properly.

I would propose coming with a solution that makes all necessary checks "after" fixing the block to see if it works well. We can then compare both solutions and decide which one to (fix) and take.

[Garry Yao]

Replying to fredck:

The proposed patch is not handling collapsed selections inside text nodes properly.

I would propose coming with a solution that makes all necessary checks "after" fixing the block to see if it works well. We can then compare both solutions and decide which one to (fix) and take.

• 3684_2.patch is an enhancement of original approach;
• 3684_3.patch is following your proposal;

Please compare these two while reviewing.

[Martin Kou]

3684_3.patch is causing some strange selection shifts when the editor document has more than 1 non-enter mode blocks at the end. e.g.

1. Open replacebyclass.html in IE.
2. Press Enter at the end of the first paragraph to create a new paragraph.
3. Inside the new paragraph, change the paragraph format to "Normal (DIV)".
4. Press Enter again to create another DIV. Now you should have to DIV paragraphs at the end of the document.
5. Click on the first DIV paragraph - no problem.
6. Click on the second DIV paragraph - a P paragraph is created (which is ok), and the caret shifts into the newly created P (this is wrong).

[Garry Yao]

It seems that in IE it's possible to leak selection into body even for block element like 'div' and 'blockquote', so we should disable the possibility of exiting from them with a new paragrah.
After the patch, it's still possible for user to exit from no matter what block. E.g, if you want to exit from, let's say a 'div' into a 'p', you can press enter at the end it, and change newly created 'div' into 'p'.

[Garry Yao]

Fixed with [3672]. Click here for more info about our SVN system.