whitespace trimming within pre tags

[David Au]

Leading whitespace within a pre tag is being trimmed. This is an issue because the text within the pre tag is expected to be preserved 'as is'.

1. To reproduce this issue, paste the following into FCKeditor's Source view:

   <pre>
   
     /***
      * First line (above) has leading whitespace.
      * Some more text...
      */
      public void testFunction(){
        System.out.println( "abc" );
      }
   </pre>
   

2. Next press the Source button to return to the normal view.
   
3. Now press the Source button two more times and you will see that the leading whitespace on the first line has been removed.

This issue exists on Firefox 2.0.0.3 and IE 7.0.5730.11 (both on WinXP).

[Frederico Caldeira Knabben]

Confirmed with IE6 FF2.

[Alfonso Martínez de Lizarrondo]

The problem is that pre is marked as a block element so these lines get executed in fck_xhtml.js:

 // Trim block elements. This is also needed to avoid Firefox leaving extra
 // BRs at the end of them.
 if ( isBlockElement )
   FCKDomTools.TrimNode( htmlNode, true ) ;

Also, when the user presses enter inside a pre by default the pre is splitted like it would happen with p or other elements, but in this case I think that it's better to always generate a br.

I've done a little test but I haven't managed to find the proper fix.

[Martin Kou]

I've committed a partial fix in [499], which makes FCKDomTools.TrimNode() ignore <pre> tags. The rationale is that the starting and ending whitespaces in a <pre> tag are visible, unlike other tags. Trimming them would change the document's appearance, which I guess is not the intention of FCKDomTools.TrimNode().

It is possible to change the enter key behavior when the user is inside a <pre> tag as well. It makes sense to add <br> tags for enter taps in a <pre>, instead of splitting up the <pre>. But there's one problem here though, how is the user supposed to leave the <pre> tag? Maybe two enter taps?

[Martin Kou]

I've discovered another whitespace trimming issue with <pre> tags. By applying the test case given in ticket #346 in Internet Explorer:

<pre>

  /***
   * First line (above) is blank.
   * Some more text...
   */
   public void testFunction(){
     System.out.println( "abc" );
   }
</pre>

Switching between source and WYSIWYG mode after that, once, would delete the first line break. Switching again would delete the second line break.

After some experiments, the culprit to this problem is found to be the Microsoft.XmlDom ActiveX we're using to reassemble the document between mode switches. The xml property's value of this ActiveX object would chop exactly one newline character off from the beginning of the <pre> tag, if one can be found.