Table width not being obeyed (trunk builds only, latest 0.9.1 branch works fine)

VERIFIED FIXED in mozilla0.9.2

Status

()

Core
Layout: Tables
P2
normal
VERIFIED FIXED
17 years ago
17 years ago

People

(Reporter: Grey Hodge (jX), Assigned: karnaze (gone))

Tracking

({regression})

Trunk
mozilla0.9.2
x86
Windows 98
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

17 years ago
Well, basically this page is being rendered REALLY wide, I think the error is
occuring in the following line:
<td width="143" align="left" valign="top" bgcolor="#ff4a14">
where the width="143" isn't being obeyed. There are a bunch of GIF buttons, and
rather than putting a <br> between them, the writer depended on the table width
limit to force them to auto-wrap to the next line. With the WIDTH being ignored
it lays out those GIFs on a horizontal line, making the page mucho-wide-o.

Again, this is only on the trunk builds. The 0.9.1 branch works fine.

Comment 1

17 years ago
Seen on both Windows and Linux builds, 20010605-0606.  Someone on #mozillazine
reported seeing it on 2001060115 but not 2001052721 (both Linux).  All of these
are on trunk only.
Arrghh! That's exactly what we want in bug 32191, but it does not work there.
Is it because of the <a>?
Hmm. The table is inside a <td nowrap>.
(Reporter)

Comment 4

17 years ago
YEs, but that's another table's tag. Here is the line you mention, and the very 
next line:

        <TD align=left valign="top" nowrap>
                <table border="0" cellpadding="0" cellspacing="0">

You can see that the NOWRAP belongs to the table that the problem table resides 
in. The rest of the cells in this table have absolute pixel widths specified.
Removing the "nowrap" solves the problem. But I think this is only because of
bug 32191. If the table has { table-layout: auto } (the default) we should
ignore an explicit width if it is smaller than the minimum content width.

Comment 6

17 years ago
Created attachment 37513 [details]
testcase

Comment 7

17 years ago
I think we inherit the nowrap attribute. I backed out my last checkin, but the 
problem remained.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 8

17 years ago
the testcase renders fine with 2001053004. It would be very good to verify with
a build from 20010531 in the evening after hyatts checkin and may be 20010602. (
I am on a terrific slooow network now, so I can't test it)

Comment 9

17 years ago
I just tested with 2001060106/Linux, and it renders incorrectly.

Comment 10

17 years ago
CC: hyatt this looks pretty much like a consequence of the big style checkin
(Assignee)

Comment 11

17 years ago
Created attachment 37537 [details] [diff] [review]
patch to fix the bug (but it hasn't been tested)
(Assignee)

Comment 12

17 years ago
I think Hyatt is doing the right thing, but tables needed to react a bit. I'm 
not sure what else needs to. I'm hoping that the patch will also fix some other 
nowrap table bugs. 
Status: NEW → ASSIGNED
Keywords: regression
Priority: -- → P2
Target Milestone: --- → mozilla0.9.3
(Assignee)

Comment 13

17 years ago
I'm moving this to m0.9.2. I'm sure there are lots of other sites affected.
Keywords: patch
Target Milestone: mozilla0.9.3 → mozilla0.9.2
(Reporter)

Comment 14

17 years ago
I've done more looking around with trunk builds, and yes, there are other sites
affected by this. I'm trying to find a few nice ones that can be boiled down to
a good solid testcase, as opposed to wandering table-aligned sites. I will try
to have a good one over the weekend.

Comment 15

17 years ago
nice cleanup, r=peterl

Comment 16

17 years ago
Chris, why does white-space have to be set to 'normal' in the CSS file? That is
the default value according to CSS2. Is that just left-over from your testing?
(Assignee)

Comment 17

17 years ago
Oh, I thought inherit was the default, and it is being inherited.

Comment 18

17 years ago
CSS2 says it is normal (http://www.w3.org/TR/REC-CSS2/text.html#propdef-white-space)

I could not find anything in the errata suggesting that thsi has changed, so
I'll look into why it is being inherited (possibly another bug).

What testing has the patch had (comment say untested)?
(Assignee)

Comment 19

17 years ago
Created attachment 38088 [details] [diff] [review]
tested patch which works around block bugs, more compatible with IE and spec

Comment 20

17 years ago
r= alexsavulov

Comment 21

17 years ago
sr=attinasi

Comment 22

17 years ago
a= asa@mozilla.org for checkin to the trunk.
(on behalf of drivers)
Blocks: 83989
(Assignee)

Comment 23

17 years ago
The 3rd attachment has been checked in, marking fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
(Reporter)

Comment 24

17 years ago
Looks good. Can't see the bug anywhere. Go grab a grape nehi and relax.

Comment 25

17 years ago
 The checkin fixed the bug.. I dont see the page rendered wide..
Build ID # 2001073003
Platform: WIN98
Marking verified 
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.