95512 - lxr sized incorrectly and reflows oddly

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

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

Between 2001-08-13-08 and 2001-08-13-21 builds the initial layout of
http://lxr.mozilla.org/seamonkey/ was changed from one that looked reasonable to
one where the text is wrapped rather oddly:

Use this field to
find
a particular 
[etc...]

Furthermore, in the later build (and ones after it), when one types in the text
inputs, the layout changes.

Comment 1

[Marc Attinasi]

maybe the change to nsBlockFrame.cpp v3.450 that I checked in for Alex on
08/13/2001 17:08? Alex, do you want to chek it out?

reassigning...

Comment 2

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

This was caused by the checkin for bug 93363 (rev 3.450 of nsBlockFrame.cpp).

Comment 3

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

Working on patches in bug 95511.

Comment 4

[Alexandru Savulov]

Attachment: reduced test case

Comment 5

[Alexandru Savulov]

the fix for bug 93363 was about to prevent that blocks that should wrap, wrap
even if they are contained in nowrap blocks. on the lxr page we ahve the
following situation:

<td VALIGN=TOP NOWRAP>

...
<table BORDER=0 CELLPADDING=2 CELLSPACING=0>
...
<td><font SIZE="-1">
Use this field to search<br>through all the text.</font>
</td>
...

before the fix of 93363 the text "use..." didn't wrap, now it wraps.

what do we want?

Comment 6

[Marc Attinasi]

Looks like the LXR problem is actually bad markup. The fact that have BR
elements in there makes it look like they were trying to work around the
original bug (not wrapping when it should have been). I'd say this is an
'evangalism' issue, actually. What do you think, David?

Comment 7

[Alexandru Savulov]

sorry in my previous comment i use the term "prevent" instead of "assure"

Comment 8

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

In that case maybe the later patch on bug 95511 is sufficient.

Comment 9

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

Yes, my patch on bug 95511 fixes the incremental reflow problems.

Comment 10

[Alexandru Savulov]

I will try to get hold of the LXR guys so that they change the HTML on those pages.

Comment 11

[Alexandru Savulov]

Opened bug 95691 for the "evangelization" of LXR pages.

Comment 12

[Alexandru Savulov]

Attachment: testcase - demonstrates the incremental problem in NS6.1 too

Comment 13

[Alexandru Savulov]

David, please check this out in NS6.1 .

I added here a new testcase( attachment 46269 [details] ). Open it in NS6.1 and watch the
height of the innermost cells(red) while you type text in inputs. (type first in
the upper one, then lower one)

NS6.1 does not contain my patches. Is still the version that uses Karnaze's
temporary patch for 57828. I'm tracking the cause and it seems that is happening
on the table level while balancing. (not sure though...) 

Comment 14

[Alexandru Savulov]

also check the test file

file:///s|/mozilla/layout/html/tests/table/bugs/bug2479-5.html

on the bottom of the page there is an input that causes the same behaviour in NS6.1

Comment 15

[Alexandru Savulov]

Attachment: another testcase (check NS6.1 too)

Comment 16

[Alexandru Savulov]

ok the only valid attachment for this bug is

http://bugzilla.mozilla.org/showattachment.cgi?attach_id=46269

Comment 17

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

The patch on bug 97383 fixes this and the underlying problem behind bug 57828.

Comment 18

[Alexandru Savulov]

marking as fixed