238472 - {inc} table cell too narrow

Status: RESOLVED FIXED

(Core :: Layout: Block and Inline, defect, P1)

Description

[Andrew Schultz]

this bug (mentioned by bryner in bug 232838 comment 20) makes the text at the
top of bonsai wrap too much.  the problem is that the text's table cell is too
narrow.

the bug occurs with linux trunk build 2004032208 and older builds back to 1.0,
although I didn't see a dupe.  The bug's appearance on bonsai is relatively
recent, but appears to have simply been exposed as the testcase I'll attach
occurs with older builds.  also, adding "document.body.offsetHeight" at the
appropriate place makes the bug occur with older builds.

Comment 1

[Andrew Schultz]

Attachment: testcase

with linux trunk 2004032208, the text appears as:

Mail
people

it should be

Mail people

Comment 2

[Bernd]

Attachment: testcase both tables should be identical

The problem here is that during incr. reflow the block with the inline reports
the available width back as the desired width. And then the table in auto mode
sees the small desired width and gives the block what it requires. A block
without inline frames reports a larger desired width back and then the text
doesnt wrap.
Bug 63916 is a similiar issue with inlines.

Comment 3

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

In the buggy case we're incorrectly setting the "wrapped" bit on the line with
the BR, so the check of the previous line's wrapped bit in
nsBlockFrame::ReflowLine fails.  (I say incorrectly, not because it's documented
what it should mean, but because there are two callers that assume that a line
terminated by a BR should not have its "wrapped" bit set --
nsBlockFrame::ReflowLine and nsLineLayout::VerticalAlignFrames.)

Comment 4

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

Attachment: patch

This has some other comments I've added to nsBlockFrame.cpp since I last
checked in to the file.

Comment 5

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

Attachment: patch (diff -ub)

Comment 6

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

What was going on here is that a BR generates a break-after status, but without
NS_FRAME_IS_NOT_COMPLETE.  However, when it's inside an inline, the inline
reports break-after *and* NS_FRAME_IS_NOT_COMPLETE.  So I think it's the first
of the two real changes that fixes the bug, but I made the second one anyway
(although I'm not really sure when we'd execute that codepath).

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 144685 [details] [diff] [review]
patch (diff -ub)

thanks guys!

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Do you think we should take this for 1.7final? If we're sure it's not a
regression than I'd be inclined to say no.

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

David, do you want to check this in?

Comment 10

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

Fix checked in to trunk, 2004-04-23 12:27 -0700.

Comment 11

[Boris Zbarsky [:bzbarsky]]

This probably improved perf some on pages with lots of <br>s too.. see bug 240282 .

Comment 12

[QuanCheng]

That's very good!!!
I really appreciate your contributions!