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.

[Martin Kou]

Oops... I hit the enter key in the description field accidentally in my last comment. Restoring to the original description.

[Martin Kou]

Another partial fix is committed to [523], which fixes the issue where line breaks immediately after a <pre> tag are chopped off when the user switches between Source and WYSIWYG modes.

The reason to the bug was even more interesting than I initially thought. The fundamental reason to the line breaks being chopped off, is because the following two <pre> tags are the same when the DOM is concerned:

<pre>some text here</pre>

<pre>
some text here
</pre>

The two <pre> tags above are identical - their innerHTML properties are identical; the node values of their only text node child are identical; the way they are displayed are identical.

This is intuitive if you're writing (X)HTML manually, but poses a problem if you have to reassemble an XHTML string by scanning a DOM tree - which is what FCKeditor does when you switch from WYSIWYG mode to Source mode. Say, for example, you have the following <pre> tag being displayed in WYSIWYG mode:

<pre>

some text here, above me is a blank line
</pre>

When you switch from WYSIWYG to Source, FCKeditor, or more precisely, the XHTML reassembler in FCKeditor, sees the <pre> tag to contain a text node with "\nsome text here, above me is a blank line" as innerHTML or as its text child node value. When the reassembler rewrites the DOM tree as an XHTML string, it naturally writes:

"<pre>\nsome text here, above me is a blank line</pre>"

Or something similar to that. However, as I've written earlier, this is identical to the <pre> node without the line break at the beginning - thus, effectively, one line break is chopped off.

[Frederico Caldeira Knabben]

Based on your comments Martin, it is safe to say that the outputted <pre> tag inner data must be:

'\n' + <pre>.innerHTML + '\n'

Do you confirm it?

[Martin Kou]

[637] has fixed the issue where if the <pre> block is at the end of the document, the user will have no simple way of escaping the <pre> block.

[638] has fixed the issue where if the user presses Enter in a <pre> block, the block is split into two. Now pressing Enter in a <pre> block creates a <br>.