element.innerHTML = element.innerHTML changes layout in Firefox 4

I found a strange issue when browsing the older Ext documentation, http://extjs.cachefly.net/ext-3.2.1/docs/?class=Ext.grid.PropertyGrid

The layout of the inheritance box (top right) is somewhat shattered.

broken layout http://img339.imageshack.us/img339/374/bildschirmfoto20110427u.png

But after executing

var resblock = document.getElementById('docs-Ext.grid.PropertyGrid').getElementsByClassName('res-block-inner')[0];
resblock.innerHTML = resblock.innerHTML; // should be a no-op(?)

everything is okay.

okay layout http://img204.imageshack.us/img204/374/bildschirmfoto20110427u.png

How can that be? A bug in Firefox 4?

Edit A minimal testcase: http://jsfiddle.net/uZ3eC/

Yes, it looks like a bug in the way Firefox 4 , over the handling of handles line endings.

The resblock element is a <pre> element containing a number of text nodes, which deal with new lines and indentations. When they are constructed through the scripts, they contain a CARRIAGE RETURN (U+000D) followed by a sequence of non-breaking spaces.

However, after running resblock.innerHTML = resblock.innerHTML; they now contain a LINE FEED (U+000A) followed by the non-breaking spaces.

It seems that Firefox 4 is only treating the line feed character as a line break, and rendering the parts of the class hierarchy on new lines.

Edit: What Boris said.

The HTML5 draft spec Section 8.2.2.3 Preprocessing the input stream says:

U+000D CARRIAGE RETURN (CR) characters and U+000A LINE FEED (LF) characters are treated specially. Any CR characters that are followed by LF characters must be removed, and any CR characters not followed by LF characters must be converted to LF characters. Thus, newlines in HTML DOMs are represented by LF characters, and there are never any CR characters in the input to the tokenization stage.