Opened 17 years ago

Closed 17 years ago

Last modified 15 years ago

#328 closed Bug (fixed)

whitespace trimming within pre tags

Reported by: David Au Owned by: Martin Kou
Priority: Normal Milestone: FCKeditor 2.5 Beta
Component: General Version: FCKeditor 2.4.1
Keywords: Confirmed Cc:

Description (last modified by Martin Kou)

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:
       * First line (above) has leading whitespace.
       * Some more text...
       public void testFunction(){
         System.out.println( "abc" );
  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 and IE 7.0.5730.11 (both on WinXP).

Change History (9)

comment:1 Changed 17 years ago by Frederico Caldeira Knabben

Keywords: Confirmed added; pre removed

Confirmed with IE6 FF2.

comment:2 Changed 17 years ago by 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.

comment:3 Changed 17 years ago by Frederico Caldeira Knabben

Milestone: FCKeditor 2.5

comment:4 Changed 17 years ago by Martin Kou

Owner: set to Martin Kou
Status: newassigned

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 17 years ago by Martin Kou

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:


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

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 17 years ago by Martin Kou

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 17 years ago by 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>
some text here

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:


some text here, above me is a blank line

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 17 years ago by 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?

comment:9 Changed 17 years ago by Martin Kou

Resolution: fixed
Status: assignedclosed

[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 – 2022, CKSource sp. z o.o. sp.k. All rights reserved. | Terms of use | Privacy policy