Opened 9 years ago

Closed 9 years ago

Last modified 7 years ago

#328 closed Bug (fixed)

whitespace trimming within pre tags

Reported by: decinz Owned by: martinkou
Priority: Normal Milestone: FCKeditor 2.5 Beta
Component: General Version: FCKeditor 2.4.1
Keywords: Confirmed Cc:

Description (last modified by martinkou)

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>
    
  1. Next press the Source button to return to the normal view.
  2. 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).

Change History (9)

comment:1 Changed 9 years ago by fredck

  • Keywords Confirmed added; pre removed

Confirmed with IE6 FF2.

comment:2 Changed 9 years ago by alfonsoml

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.

comment:3 Changed 9 years ago by fredck

  • Milestone set to FCKeditor 2.5

comment:4 Changed 9 years ago by martinkou

  • Owner set to martinkou
  • Status changed from new to assigned

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?

comment:5 Changed 9 years ago by martinkou

  • Description modified (diff)

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.

comment:6 Changed 9 years ago by martinkou

  • Description modified (diff)

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

comment:7 Changed 9 years ago by martinkou

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.

comment:8 Changed 9 years ago by fredck

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?

comment:9 Changed 9 years ago by martinkou

  • Resolution set to fixed
  • Status changed from assigned to closed

[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>.

Note: See TracTickets for help on using tickets.
© 2003 – 2016 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy