lxr sized incorrectly and reflows oddly

RESOLVED FIXED

Status

()

Core
Layout
RESOLVED FIXED
17 years ago
17 years ago

People

(Reporter: dbaron, Assigned: Alexandru Savulov)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

17 years ago
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

17 years ago
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...
Assignee: karnaze → alexsavulov
(Reporter)

Comment 2

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

Comment 3

17 years ago
Working on patches in bug 95511.
(Assignee)

Comment 4

17 years ago
Created attachment 46017 [details]
reduced test case
(Assignee)

Comment 5

17 years ago
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

17 years ago
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?
(Assignee)

Comment 7

17 years ago
sorry in my previous comment i use the term "prevent" instead of "assure"
(Reporter)

Comment 8

17 years ago
In that case maybe the later patch on bug 95511 is sufficient.
(Reporter)

Comment 9

17 years ago
Yes, my patch on bug 95511 fixes the incremental reflow problems.
(Assignee)

Comment 10

17 years ago
I will try to get hold of the LXR guys so that they change the HTML on those pages.
(Assignee)

Comment 11

17 years ago
Opened bug 95691 for the "evangelization" of LXR pages.
Depends on: 95691
(Assignee)

Comment 12

17 years ago
Created attachment 46269 [details]
testcase - demonstrates the incremental problem in NS6.1 too
(Assignee)

Comment 13

17 years ago
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...) 
(Assignee)

Comment 14

17 years ago
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
(Assignee)

Comment 15

17 years ago
Created attachment 46491 [details]
another testcase (check NS6.1 too)
(Assignee)

Comment 16

17 years ago
ok the only valid attachment for this bug is

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

(Reporter)

Comment 17

17 years ago
The patch on bug 97383 fixes this and the underlying problem behind bug 57828.
(Assignee)

Comment 18

17 years ago
marking as fixed
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.