ENTER key destroys part of the text

[wim.dewijngaert@…]

Enter the following code in the editor, put the cursor just behind www.xxx.be and press ENTER. Everything below this line is DELETED (serious bug if you ask me).

<p><font color="#993366"><font color="#000000">La zone:</font></font></p><p><font color="#000000">- le Règlement de police (<font color="#0000ff">dans ce site aussi</font>)</font><br /><font color="#000000">- un répertoire téléphonique</font><br /><font color="#000000">- des liens utiles </font><a href="http://www.polbru.beListe"><font color="#993366" /></a><br /><a href="http://www.xxx.be"><br />www.xxx.be</a><font color="#993366"><a href="http://www.polbru.beListe"><font color="#993366"><font color="#993366"><br />Liste des commissariats et services de garde</font><br /><font color="#000000">Direction générale<br />Rue Marché au Charbon 30<br />1000 Bruxelles<br />Tél. 02 279 77 11 – fax 02 279 77 15<br />Service de garde 24/24</font><br />&#160;<br /><font color="#000000">12ème division (Laeken)<br />Avenue Houba de Strooper 141<br />1020 Bruxelles<br />Tél. 02 279 82 10 – fax&#160; 02 279 82 09<br />Ouvert de 7 à 22:00<br />&#160;<br /></font></font></a><font color="#993366"><br /></font></font></p><p>District 1</p>

[anonymous]

Tested on IE6. In FF nothing is deleted but the cursor behaves funny.

[Frederico Caldeira Knabben]

Confirmed with IE6.

This is a reduced source for testing:

<p>
	Place the cursor right before the following link and hit enter.</p>
<p>
	This is some text<br />
	<font color="#993366" />
	<br />
	<a href="http://www.xxx.be">
		<br />
		Link</a><br />
	The link and this text will be deleted.
</p>
<p>
	Another paragraph.
</p>

The problem disappears by removing the self-closing <font /> or the <br /> inside the <a>.

[Frederico Caldeira Knabben]

Recent changes in the code (available in the SVN) now prevent the editor to output invalid self-closing tags (like the above <font />), which are the cause of this problem.

The problem is that the IE DOM is broken on such cases, and so manipulations on it may cause unexpected results. Actually their DOM implementation is quite buggy.

Being not able to produce such invalid code will prevent the problem, so, it is a first step to fix it.

It remains the problem when loading code already broken. We could fix it by removing invalid tags from the source before loading it, but I would really avoid adding further overhead in the loading process.

Other that that, with the SVN version, once the broken code is loaded and saved, it gets fixed, so the problem would not happen again.

So, is the be prevention described above enough for it, or we really should care of already broken stuff?

[wim.dewijngaert@…]

Having your text dissappear without warning is a big no-no, even if the code is not correct html. How much does this influence the loading times?

[Frederico Caldeira Knabben]

A possible fix would be a simple replace when loading the data in the editor something like this (not tested):

html = html.replace( /(<(?!base|meta|link|hr|br|param|img|area|input)([^ >]+)[^>]*?)(\/>)/gi, '$1></$2>' ) ;

The fact is that we already do a series of tests in the input code, so we prefer to avoid introducing further overhead. Some tests should be done to really understand the impact of the above solution.

[Frederico Caldeira Knabben]

#200 is a DUP of this.

[Frederico Caldeira Knabben]

Ok... fixed with r188:190. The closing tag is now being added to invalid self-closing tags.