19961 - Table cell not obeying specified width, height

Status: VERIFIED FIXED

(Core :: Layout: Tables, defect, P2)

Description

[richard]

The left cell is not obeying the width of 150 pixels given to it specifically
when the right cell does not contain enough content to fill out the rest of the
100% width on the table. The engine should restrict the left column and let the
right column (whose width is unspecified) stretch to the remainder of the table
width regardless of the content therein. Renders properly in IE 4/5.

Comment 1

[akana]

On NT 4.0 sp4, Mozilla-Win32-M11-fullcircle build 1999111520 and Netscape 4.7
behaves identically: neither one splits "too long" text line in the two lines
and both allow left cell grow over 150 pixels. IE 5.00 honors left cell
restriction.

I think this is somewhat basic table handling. So it seems this behavior is more
like a feature than a bug for NS-alike products :).

Anyway, here's shrinken test case from given URL (XHTML things (XML) and
unnecessary margin settings could be further removed):

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/transitional.dtd">
<html xmlns="http://www.w3.org/TR/xhtml1">
<head>
</head>
<body topmargin="0" leftmargin="0" marginwidth="0" marginheight="0">
<table border="0" cellpadding="0" cellspacing="0" width="90%">
<tr>
  <td width="150">
    Over 100 Local Wedding Professionals
  </td>
  <td>
    <font size="6">Business Directory</font>
  </td>
</tr>
</table>
</body>
</html>

Comment 2

[karnaze (gone)]

Adding layout keyword.

Comment 3

[Christian Mattar]

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

Comment 4

[Christian Mattar]

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

Comment 5

[Christian Mattar]

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

Comment 6

[Christian Mattar]

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

Comment 7

[Christian Mattar]

Attachment: simplified testcase

Comment 8

[ekrock's old account (dead)]

Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!

Comment 9

[Christian Mattar]

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

Comment 10

[Christian Mattar]

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

Comment 11

[Richard Zach]

I'm adding HEIGHT since the same problem arises here.  If you have a TABLE of
height 100%, and two cells, one with a specified height, both grow to 50% of the
table height.  Attaching a testcase.

Comment 12

[Richard Zach]

Attachment: Testcase for HEIGHT attribute

Comment 13

[Christine Hoffman]

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

Comment 14

[Christine Hoffman]

Attachment: Attaching a testcase from dup bug #26665 with comment on code

Comment 15

[karnaze (gone)]

We could make it work this way in standard mode. Marking remind.

Comment 16

[Christine Hoffman]

Spoke with Karnaze and he agreed that this bug is not REMIND. Reopening with new 
testcase and nominating it for beta2.

Comment 17

[Christine Hoffman]

Attachment: testcase to demonstrate problem

Comment 18

[Christian Mattar]

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

Comment 19

[Blake Ross]

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

Comment 20

[karnaze (gone)]

Moving to M17.

Comment 21

[karnaze (gone)]

This bug has a lot of duplicates, justifying the nsbeta2 nomination.

Comment 22

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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

Comment 23

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Attaching two testcases which are basicly the same. They tests both width and 
height. The first testcase has some scripts that allow easy viewing of all 
sizes as well as chaning size of the content of one cell. (The float:left is a 
workaround for bug 39683)

The width of col 2 and the height of row 2 should be ~50px.
col 1 and col 3 should have the same width.
row 1 and row 3 should have the same height.

The column widths seems to work in this testcases but the row heights dosn't.

IE does not render this correctly.

Comment 24

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Attachment: Testcase for both width and height. See my comments 2000-05-17 18:36

Comment 25

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Attachment: Testcase for both width and height. See my comments 2000-05-17 18:36

Comment 26

[leger]

Putting on [nsbeta2-] radar.

Comment 27

[Christian Mattar]

Adding keyword, sorry for the spam!

Comment 28

[Bart Szyszka]

I'm not sure if this has to do with Mozilla's height stuff, or if perhaps it has
more to do with its padding, but the following are examples of web sites where
Mozilla adds some sort of padding to the cells while no padding or margins or
any spacing should be there:
http://www.gigabee.com
http://konverse.sourceforge.net/default.php

(right now that default.php is needed, FYI)

I don't think any other browser is having problems with these two sites,
including KDE2's Konqueror. They both contain valid code.

Comment 29

[Bernd Mielke]

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

Comment 30

[ddet]

Another example for problems with height/width results in wrapping cell content
where none should be:

http://www.evangelium.de

The title bar normally is shown as a continuous shadowed bar with logo to the
left an linkbar to the right.  Also the two input fields should be shown side by
side. IE  and NC4.7x do not have problems with that.

Comment 31

[shatfield]

This is not entirely fixed yet. The last 2 Test cases (5/17/00 18:38 and 
5/17/00 18:41) seem to be fine, but the "testcase" to demonstrate problem 
4/28/00 18:58) still shows that when you assign the first column to 150px, and 
leave the 2nd column unassigned, Mozilla ignores the 150px altogether, and the 
resulting column width is arbitrary.

Comment 32

[Marc Attinasi]

Denying for beta3: not critical to release.

Comment 33

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

The two pages Bart Szyszka mentioned on 6-25 are duplicates of the invalid bug
22274 and are not related to this bug.

Comment 34

[timeless]

Help wanted.

Comment 35

[Bernd Mielke]

I am just trying to figure out what is going on in BasicLayoutStrategy.
see:

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

Comment 36

[Christine Hoffman]

Going back to the original problem. A table has a width of 100% and contains 2 
cells. The first cell has a specific width of 150px; the second cell has no 
specific width. The table should render the first cell at 150px and expand the 
second cell across the remaining table. 

Netscape 6 does not honor the 150px value until the second cell has enough 
content to push the first cell back to 150px. 

Simplified testcase attached.

There is another bug #33137 with a similar generic summary (<td> width attribute 
ignored). The issue, however appears to be a separate one.

Removing 'nsbeta3-' and renominating this bug for nsbeta3+ consideration. 

Comment 37

[Christine Hoffman]

Attachment: Testcase to demonstrate original 'width' problem

Comment 38

[Bernd Mielke]

Found a  fix for the width, regression tests still ahead.

Comment 39

[Christine Hoffman]

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

Comment 40

[Marc Attinasi]

Who marked this NSBETA3+? Anyway, denying for beta3. Chris, please chek out the 
possibility of implementing the IE behavior in standard mode if it is correct. 
Current pages will be fine rendered as Nav does it, so this is not critical for 
RTM.

Comment 41

[timeless]

Marc according to "View Bug Activity" 
http://bugzilla.mozilla.org/show_activity.cgi?id=19961
[e-mail]

Silly questions don't deserve answering. Useful questions do. Chris did you 
have a reason for +'ing this bug (including PDT consnet)?

At the risk of being thuroughly annoying i should remove your [nsbeta3-] 
because chris can't work on it otherwise, and you just asked him to.

Comment 42

[Bernd]

Attachment: patch

Comment 43

[Bernd]

I just attached the patch in order to demonstrate the idea how one could solve 
the width problem. It fixes the testcases for the width. I am trying to check it 
against the regression tests (rtest.bat) but experience a lot of difficulties 
(isn't that a nice word for bug :-)).

Comment 44

[Bernd Mielke]

And the regression test failed, due to a coding error. So please ignore the 
patch now, there will be soon something better.

Comment 45

[Bernd Mielke]

A quote from:
http://lxr.mozilla.org/seamonkey/source/layout/html/table/src/nsTableFrame.cpp#3
459
 which seems to be related to the height problem:

// proportionately distribute the excess height to each row. Note that we       
// don't need to do this if it's an unconstrained reflow

Comment 46

[Bernd Mielke]

Attachment: corrected patch

Comment 47

[Bernd Mielke]

Attachment: regression tests

Comment 48

[Bernd Mielke]

The proposed path fixes the width problems as outlined in this bug. I tested the
patch against the table testcases as required in the regression tests. The patch
fixes also the numerous duplicates. So it needs a review.

Comment 49

[Bernd Mielke]

I was probably so impressed by my patch that I did not read the commented 
out code:
http://lxr.mozilla.org/seamonkey/source/layout/html/table/src/BasicTableLayoutSt
rategy.cpp

line 323 and 328ff. 
It does exactly the same. 

Only the nasty NavQuirks are there. :-(

According to CVS blame this line was commented out for a fix of bug 14332. I 
think that it was not necessary to comment out these lines. They do not 
influence the testcases from bug 14332 (with and without NavQuirks).

Comment 50

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Please don't do this in NavQuirks only. The *suggestion* from w3c on automatic 
tables isn't really useful and is (I think) mostly designed for backwards 
compability.

Comment 51

[Bernd Mielke]

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

Comment 52

[karnaze (gone)]

In standard mode, the fixed width is now being honored. The height problem has 
not been addressed. I'm marking this nsbeta3-. 

Comment 53

[Avi Drissman]

> In standard mode, the fixed width is now being honored.

I'm sorry; I'm a bit new to the party, and I'm a bit confused. So if I am not making much 
sense, please bear with me, OK? Thanks.

In bug 51534, which is a dup of this one, I made an attachment (http://
bugzilla.mozilla.org/showattachment.cgi?attach_id=14095) to illustrate this problem. 
Since this is supposedly fixed for widths, I'm trying to view it with the latest Moz build 
(2000090820 Mac). It has no DTD declaration, so it renders in quirks mode, and doesn't 
get this fix. But if I give it a DTD of Transitional HTML 4, it still renders incorrectly. (View 
the bug's URL referenced-page for a live example of the HTML marked as transitional.)

Is there a quick explanation anywhere what makes gecko trigger quirks mode? Why is 
my sample still not laying out correctly?

Comment 54

[buster]

Avi:  The fix was checked in 9/10/2000. You are using a version of the browser 
from 9/8/2000.  So I suggest you download today's daily build when it is ready, 
and try again.

Comment 55

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

The width problem has not been fixed (or has regressed). Removing nsbeta3- for 
reevaluating.

The only attatched testcases where the width worked is the testcases from 
05/17/00 (8817 & 8818). Tested on Win98SE with build 2000-09-12-08

Comment 56

[Christine Hoffman]

Not fixed as of 9/12 build.

Comment 57

[Bernd Mielke]

Attachment: testcase in standard mode

Comment 58

[Bernd Mielke]

>>>In standard mode, the fixed width is now being honored.

exactly

here comes the line 326 from BasicTableLayoutStrategy.cpp
PRBool onlyAllocateAutoCols = (totalCounts[DES_CON] > 0) && !mIsNavQuirksMode;

That means all testcase, where the Quirkstylesheet is enabled will not render
correctly. See my previous comment about NavQuirks. Also the behviour of the
majority of the files listed in the regression test do not change theire buggy
behaviour. The question here is whether one would like to propagate the buggy
Nav behaviour into the future. Nobody (including the qa contact) will understand
this ;-).

Comment 59

[karnaze (gone)]

I would like very much to make it work correctly even in quirks mode. I'm CCing 
ekrock to see what he has to say. 

Comment 60

[Avi Drissman]

Sorry about using 2000090820. That was the latest Mac nightly and I realized my 
mistake just after posting.

That said, it still doesn't work in 2000091220 Mac.

Comment 61

[Bernd Mielke]

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

Comment 62

[Amaury Jacquot]

There is also another issue related to scrolling
when a table has some padding or border AND width=100%, then the horizontal
scrollbar kiks in. I think it also does for the height and the horizontal 
scrollbar...

Comment 63

[Christine Hoffman]

Tested with current builds on Win, Mac and Linux. Fixed in 'standard' mode, 
behaves like Nav in 'quirks'. I guess this is pending a decision of whether to 
correct this in 'quikrs' mode.

Comment 64

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

There are quite a number of dups to this one and proboly all of them come from 
pages rendered in quirks mode. Also IE does this so noone should be surpriced 
if Mozilla does too. Furthermore it is more logical and intuitive behavoiur, 
not to mention the fact that the less quirks and normal differ, the better

Comment 65

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

What is the hesitation for doing this in quirks mode?  If IE does it, what pages 
could it break?

Comment 66

[karnaze (gone)]

Adding rtm+. It should work the same way in quirks and standard modes. 

Comment 67

[Phil Peterson]

PDT marking [rtm need info] since it doesn't appear that code reviews are done
for this patch.

Comment 68

[karnaze (gone)]

Attachment: most recent patch (to fix the width problem in both modes)

Comment 69

[buster]

a=buster

Comment 70

[karnaze (gone)]

Marking rtm+

Comment 71

[Phil Peterson]

rtm++

Comment 72

[karnaze (gone)]

The width now works the same in standard mode and quirks mode so that portion is 
fixed. The height issues are not as compelling and will have to wait.

Comment 73

[Christine Hoffman]

Verified this is fixed (width problem) in quirk and standard mode using 10/6 
build on Win98. ChrisK. - can you mark this fixed?

Comment 74

[Bernd Mielke]

It fixes only the width portion of the bug, which is the more important,
nervertheless this bug should not be marked fixed, instead the keywords should
move the remaining height problem after rtm.

Comment 75

[karnaze (gone)]

Adding [rtm-] since the remaining part is not critical. This gets the bug out of 
some queries.

Comment 76

[Jim Roskind]

Based on above comments, I'm marking this fixed (so that QA can do regression
testing).
Please open another bug for the remaining details.
Thanks,
Jim

Comment 77

[Christine Hoffman]

The original problem in this bug was the width problem. That has been fixed and 
I am verifying it so (on branch). Adding vtrunk keyword.

Comment 78

[Asa Dotzler [:asa]]

Verified Fixed on trunk builds with 8/23 testcase
linux 101708 RedHat 6.2
win32 101704 NT 4
mac 101704 Mac OS9
Setting bug to Verified and removing vtrunk keyword

Comment 79

[Asa Dotzler [:asa]]

really removing vtrunk keyword and setting bug to verified.  sorry for the spam.

Comment 80

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

What is the bug number on the remaining issues (heights)?  (I assume such a bug
has been filed since this bug is marked verified.)

Comment 81

[robin shaw]

david, they are working(?) on the table height issue in bug #26183,

Comment 82

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

That bug is unrelated.

Since there were no other responses to my question, I filed bug 58402.