No steps to reproduce with input; filed based on code inspection. Both the XML parser and the HTML5 parser can put a carriage return in a text node. While searching through layout, I noticed that nsTextFrameUtils.cpp doesn't treat \r as whitespace-ish. I'm not quite sure if it should, but I suspect it should. I'm also not quite sure if \r should be treated like \n or like \t or like ' '.

Steps to reproduce: 1) Load http://software.hixie.ch/utilities/js/live-dom-viewer/saved/520

In the light of two dups, isn't this serious enough for a quick fix?

I really agree, because I don't think we're the only one with this problem - but probably lots of people don't remark it first.

not going to track this for Firefox 5. try for mozilla-central in the next two weeks so it can make 6.

this doesn't feel version specific, when it's ready, if you need on a branch then ask for approval.

> I'm not quite sure if it should, but I suspect it should. I'm also not quite > sure if \r should be treated like \n or like \t or like ' '. From the way I encountered this bug, a solitary \r should definitely be treated in the same fashion as \n (and not as \t or ' ').

Are bug 650643 and friends really dupes of this bug? They are about \r in the document source, and this is about \r in the DOM, no? http://www.w3.org/TR/CSS21/text.html#white-space-prop says: "The CSS 'white-space' processing model assumes all newlines have been normalized to line feeds. UAs that recognize other newline representations must apply the white space processing rules as if this normalization has taken place." Does HTML5 conflict with this?

(In reply to comment #10) > Are bug 650643 and friends really dupes of this bug? They are about \r in > the document source, and this is about \r in the DOM, no? They have escaped 
, so a carriage return shows up in the DOM. > http://www.w3.org/TR/CSS21/text.html#white-space-prop says: > > "The CSS 'white-space' processing model assumes all newlines have been > normalized to line feeds. UAs that recognize other newline representations > must apply the white space processing rules as if this normalization has > taken place." > > Does HTML5 conflict with this? CSS assumes wrong both for XML and HTML5.

At least for HTML5, I think CSS' assumption is correct: 
 is explicitly called out as not a newline in http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html#newlines. So I certainly don't think we should be treating \r like \n, but I'm not sure what we should be treating it like.

If anyone else out there is plagued by an old Bugzilla (2.14 vintage) that generates 
 for newlines and the updated FireFox no longer interprets as a newline, and results in very long mostly unreadable single line for each bug comment, the following hack in bug_form.pl will take care of the issue for you: # Fix annoying issue where new FireFox does not handle solitary CR as newline. #print $bug{'long_desc'}; my $long_desc = $bug{'long_desc'}; $long_desc =~ s/
/
/g; print $long_desc; Insert just after "Description:" where "print $bug{'long_desc'};" appears in the file. Why not upgrade to a newer Bugzilla? After all, the newer versions of Bugzilla do the right thing. Well, our version has been greatly modified over the years to meet internal needs and upgrading throws out a lot of work. So, if you are in the same situation, continue to hack until it is no longer usable or until someone figures out how to represent a newline in a simple, standard way across all platforms and technologies (or people quit pretending that their way is the only way).