620267 - All newlines immediately following a start <pre> tag get stripped

Status: RESOLVED FIXED

(Core :: DOM: HTML Parser, defect)

Description

[Stanimir Stamenkov]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9pre) Gecko/20101219 Firefox/4.0b9pre
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9pre) Gecko/20101219 Firefox/4.0b9pre

All newlines immediately following a start <pre> tag get ignored in HTML documents:

<pre>



Foo Bar</pre>

As far as I understand just the first newline following the start <pre> tag should be ignored <http://www.w3.org/TR/html5/grouping-content.html#the-pre-element>:

> In the HTML syntax, a leading newline character immediately following 
> the pre element start tag is stripped.

Reproducible: Always

Comment 1

[Stanimir Stamenkov]

Attachment: Sample test

Renders:

foo
There should be three blank lines just before this line.

bar
[ Test ]

Hitting the "Test" (DOM value) button gives:

"There should be three blank lines just before this line.

"

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Regression range from Linux x86-64 nightlies is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=83c887dff0da&tochange=d6bb0f9e9519
which is almost certainly the change to enable the HTML5 parser by default.

Comment 3

[Henri Sivonen (:hsivonen)]

I'm surprised we didn't have test coverage for this. :-(

Comment 4

[Boris Zbarsky [:bzbarsky]]

It's not actually all that surprising, given the nature of the bug.

I just tried to reproduce this by copy/pasting the source of the attachment and could not reproduce.  Then I tried downloading the attachment from Bugzilla, and that does reproduce the bug.

The key seems to be the CR characters.  If I change the file to just use Unix newlines (LF only), everything works fine.  I would expect that's what our tests test....

When you do add a test for this, make sure to comment that it depends on the windows newlines?

Comment 5

[Stanimir Stamenkov]

Sorry to spam the issue, but this was my source of finding the problem - does the text source from mail/news messages always contain CRLF line-endings, or it just happens to be on Windows?

Comment 6

[Stanimir Stamenkov]

> text source from mail/news messages

I mean with Thunderbird and SeaMonkey.

Comment 7

[Boris Zbarsky [:bzbarsky]]

No idea what gunk mailnews generates!

Comment 8

[[e-mail]]

The bug affects <textarea> too, of course. It's really weird; a textarea with N LFs before the first text (N >= 3) shows the text on the Nth line as expected; with a CR before the LFs you get the text on the N-1st line; with a CR after the first LF you get the text on the N-2nd line; with a CR after all the LFs you get the text on the N+1th line!

Comment 9

[[e-mail]]

Attachment: Proposed patch

Comment 10

[Stanimir Stamenkov]

See Bug 623288 for a similar (if not the same) problem.

Comment 12

[Boris Zbarsky [:bzbarsky]]

I think it's pretty clear that this needs to block.  Please land this?

Comment 13

[[e-mail]]

Pushed changeset 6f18c950b3b6 to mozilla-central.

Comment 14

[Henri Sivonen (:hsivonen)]

Attachment: Add tests with CRLF, CR and escaped LF

The bit binary patch is useless for review. I'll attach a more reviewable copy of those bits.

Comment 15

[Henri Sivonen (:hsivonen)]

Attachment: Content corresponding to the git binary patch

To see what's going on, you need to view this in a hex editor. :-(

Comment 16

[Henri Sivonen (:hsivonen)]

Test landed:
http://hg.mozilla.org/mozilla-central/rev/a1b954e9fa32