42832 - white-space:nowrap broken for blocks containing blocks

Status: VERIFIED FIXED

(Core :: Layout, defect, P3)

Description

[Matthias Kerkhoff]

Overview:
When the CSS property white-space is set to nowrap and the paragraph is longer 
than some (unknown to me) limit, mozzy breaks the paragraph. Should this happen?
My understanding of the CSS spec is, that it shouldn't. Furthermore, Mozilla
behaves differently, if additionally display:inline is set.

Steps to Reproduce:
View the webpage. Resize the browser window horizontally. Reopen the page with a 
different initial browser window width.

Actual Results:
Both paragraphs are wrapped to 3 lines (on my system). No. of lines depends on 
the screen resolution and the initial browser window width. If the window width 
is changed, only the first paragraph (the one with display:inline) is reflowed.
The second paragraph (whitespace:nowrap) does never change.

Expected Results:
CSS states that "white-space:nowrap" ONLY applies to block elements. From the 
results I guess that this is not the case. I may be wrong in this point. 
Anyway, it is surely wrong that the block paragraph (the second) gets broken (it 
shouldn't) and that it is not reflowed, if more space is available. 

Build Date & Platform:
M16, WinNT 4

Comment 1

[Hixie (not reading bugmail)]

RE: white-space and inline elements -- we are doing like CSS3 will [probably]
say, and applying white-space to inline elements. There is no real reason why
the CSS2 spec said that only blocks could have this property.

CONFIRMED. There sure are some weird things going on here.

Comment 2

[Pierre Saslawsky]

On Windows, if you make the window relatively small (up to the "Bonsai" button in 
the toolbar of a debug build) and load the test page, you can see the following:
- The title and the description are displayed each on a single line. It's wrong: 
they should wrap.
- The paragraphs P1 and P2 are displayed on 2 lines each. In P1, the first line 
is very long and wraps at what seems to be an arbitrary value. The second line 
displays the rest of the text. In P2, the first line wraps correctly but the 
second line is truncated at approximately the same arbitrary width as the first 
line of P1.

On Windows again, if you make the window large enough (unveil at least "Open 
Direc" from the "Open Directory" button in the tooolbar) and reload the test 
page, you have the following:
- Everything wraps.
- On resize, P1 is reflowed.

On Mac, we always have the same result which is:
- The title, the description and both P1 and P2 are each displayed on a single 
line. There isn't any truncation. The only problem, like on Windows, is that the 
first two strings are supposed to wrap.

In my opinion, we have 2 different bugs here:
- A Windows-specific bug where text measurement doesn't work correctly for very 
long strings. I think I saw something like that already a few months back. This 
bug would explain most of the weirdness and the arbitrary wraps and truncations.
- A cross-platform bug that makes these long strings enlarge the BODY width - 
which is correct - but cause the other strings (the title and the description 
underneath) not to wrap at the window width.

Reassigned to Erik to look at the Windows-specific part and reassign to Waterson 
for the rest.

Comment 3

[Pierre Saslawsky]

Ooops... In the first paragraph of my comments, instead of "In P2, the first line 
wraps correctly" please read "In P2, the first line wraps at the window width". 
That's because P2, even though it wraps more consistently than P1 in that test, 
should still not wrap at all.

Comment 4

[Hixie (not reading bugmail)]

Pierre -- you wrote:
> A cross-platform bug that makes these long strings enlarge the BODY width - 
> which is correct - [...]

Not quite, see bug 35681 for more details.

Comment 5

[Pierre Saslawsky]

*** Bug 45101 has been marked as a duplicate of this bug. ***

Comment 6

[Christine Hoffman]

Tested on the following M17 builds:
Win: 08_04_05
Mac: 08_04_04
Linux: 08_04_04

Bug only appears on Windows. Text does not wrap on Mac or Linux as expected.

Comment 7

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

If this is Windows-only, it may have to do with the new text-measurement code
Troy wrote before he left.  I think Robert may have looked at that code before,
and I haven't...  I'm also not on Windows.

How serious is this bug?  (Question to those who can see it...)

Comment 8

[Hixie (not reading bugmail)]

Attachment: Screenshot of attachement using Windows 2000 commercial build 2000080404.

Comment 9

[Hixie (not reading bugmail)]

Additional testcases:
  http://bugzilla.mozilla.org/showattachment.cgi?attach_id=12399 (simplified)
  http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/floatgrowth.html (original)

The screenshot is of http://user.cs.tu-berlin.de/~make/css_whitespace.html and
not itself as it would have you believe. Sorry! ;-)

This is IMHO very serious. It completely blocks use of white-space:nowrap, which
even Nav 4.x gets roughly right IIRC. Nominating for nsbeta3, strongly recommend
nsbeta3+. Note also that this is a regression.

If someone other than Erik could take this bug it would be a very good idea 
since Erik is overloaded with nsbeta3 bugs (14 at the last count) and will only 
have two weeks to fix them all. Reassigning to the Layout team.

Comment 10

[Hixie (not reading bugmail)]

*** Bug 47705 has been marked as a duplicate of this bug. ***

Comment 11

[Pierre Saslawsky]

We need a Windows guru to look at the text measurement code.
Kevin, Don?

Comment 12

[Suresh Duddi (gone)]

Kevin looks like your area. Is it?

Comment 13

[rods (gone)]

reassigning

Comment 14

[Marc Attinasi]

Looks to me like neither Nav 4.7x not IE 5.0 (Win) handle white-space:nowrap
correctly either.

Anyway, I think the problem may be in the code that tries to determine how big
the text should be (here it is from nsLineLayout.cpp):

    if (psd->mNoWrap) {
      // Make up a width to use for reflowing into.  XXX what value to
      // use? for tables, we want to limit it; for other elements
      // (e.g. text) it can be unlimited...
      availSize.width = psd->mReflowState->availableWidth;
    }
The availableWidth is pretty small, and clearly not long enough for the entire
line of text. I changed the code to set the availSize.width to 40,000 and it all
fits on one line, no wrapping. I changed it to 20,000 and it takes two lines.
I'm pretty sure this is the root of the evil, however I have to determine how to
deal with the comment in the original code regarding tables, and of course,
figure out what a reasonable value would be for the width of a no-wrap text line..

Comment 15

[Hixie (not reading bugmail)]

Marc: It works fine on Mac and Linux. Is nsLineLayout a Windows only thing?

Comment 16

[Marc Attinasi]

Ian: no, but the value is used in the text frame where the text measurement
happens, and that is where the Window-only code is. I'm digging into that now
trying to understand it. I think it may be that we simply cannot use the special
Win32-only method of calculating text run length when we have no-wrap set,
because there are some assumptions in there about how big the total size can be
(the value I hard-coded to 40,000 in my hack). Anyway I'll report back more info
when I figure it out. This one is actually fun!

Comment 17

[Matthias Kerkhoff]

Marc: The table comment may indicate a relationsip betweeen this bug and bug 
44506 (as Bernd pointed out there).

Comment 18

[Marc Attinasi]

I have this fixed. The WIN32-only text measurement code does not work in many 
situations, so I just added the no-wrap case to the exclusion clause that is 
already preventing special cases from using the optimized text measurement 
technique. See patch that I am about to attach.

Comment 19

[Marc Attinasi]

Attachment: Patch to fix the bug on Win32

Comment 20

[Chris Waterson]

looks good, r=waterson.

Comment 21

[Marc Attinasi]

Fix checked in: nsTextFrame.cpp

Comment 22

[Hixie (not reading bugmail)]

*** Bug 48870 has been marked as a duplicate of this bug. ***

Comment 23

[Hixie (not reading bugmail)]

VERIFIED FIXED with Windows 2000 and Linux Commercial builds 20000090808.