DESCRIPTION: Many (but not all) blank lines are being collapsed in PRE elements. Perhaps this has something to do with some line box work?? STEPS TO REPRODUCE: * load http://bugzilla.mozilla.org/show_bug.cgi?id=12272 (or probably this bug too) in apprunner and in NN 4.x and compare the positions of blank lines in the comments (which are in a big PRE) EXPECTED RESULTS: * the same ACTUAL RESULTS: * many blank lines missing in Mozilla DOES NOT WORK CORRECTLY ON: * Linux, apprunner, 1999-10-15-11-M11 WORKS CORRECTLY ON: * NN 4.x ADDITIONAL INFORMATION: I think this is a regression. I could check when it started if you want...

It's a parser bug. If you dump the content model you will see that N newlines in a row are turned into N-1 by the parser.

Also affects recent M11 on Windows NT, including 1999-10-15-11-M11, in every bug report I've viewed. If this is a parser problem, must be XP. Marking OS "All".

Are you sure this is a parser bug and not a Necko bug? I'm seeing similar problems on http://asp1.sbs.ohio-state.edu/text/severe/atltrop/ , but I can't replicate them if I save the page to a local file.

I'm also seeing this problem on text files, e.g., http://asp1.sbs.ohio-state.edu/text/severe/tropical/ABNT20.KNHC . I think this is likely Necko, not parser.

I'm not sure this is a parser bug either. It certainly doesn't show up on NT using the testcase.

If you

What I tried to say was: If you do not see these problems on NT, then perhaps it is a Linux-specific Necko bug. There is definitely something going on here, and it's been happening for a while.

Uh, Oh. DOES NOT WORK CORRECTLY ON: Windows NT, mozilla.exe, 1999-10-17-08-M11 build. Windows NT, apprunner.exe, M10 build. No "blank" lines visible in original testcase. WORKS CORRECTLY ON: Navigator 4.7 "Blank" lines visible where they belong. Tried to test http://asp1.sbs.ohio-state.edu/text/severe/tropical/ABNT20.KNHC - couldn't because of bug 16697. In the testcase, the "blank lines" show up as "0D0A0D0A" in a hex editor Have tried pages where the "blank lines" show up as "0A0A" in a hex editor, (in both cases in a PRE to sidestep Bug 16697), and everything is the same. rickg, what build were you using? I've never seen the testcase display properly on any Win32 build of Mozilla, on NT or 95. That's over at least 10 builds since I became aware of this bug.

I found the bug, and I've fixed it for windows. The reason it was difficult to diagnose was because it only happens on network URLS. If you take the test case (given) and save it to a file, this bug disappears. I'll confirm that this works on mac/linux, then I'll check in.

Fixed (and verified) on mac/linux/pc. I've also added this as a regression test. If you see other oddities, send'em my way.

With the attached testcase provided, this problem appears to be fixed in the Oct 21 build.