42443 - Empty cell isn't added when table too narrow and sizes are given in percent

Status: VERIFIED FIXED

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

Description

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

In the attached testcase a third cell should be added on the first row since the
last row contains three columns. This works correctly when the browserwindow is
above 400px wide. However if you decrease the width of the window the extracell
will dissapear when the window is approx 400px wide.

Steps to reproduce:
1. Load the attached testcase
2. Make your browser wide. ( > 500px)
3. decrease the width of the browserwindow slowly

Expected behaviour:
The table should become more and more narrow as the width of browser decreases
but always contain 3 columns

Actual behaviour:
At approx 400px the third column dissapears.

Testcase is simplifyed from http://www.altavista.com where the top banner shows
a simular jumping behaviour.

tested on Win89SE with build 2000-06-13-11

At approx 400px the third cell at

Comment 1

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

Attachment: simplified testcase

Comment 2

[karnaze (gone)]

The 3rd column is too wide at larger viewport widths. I need to change things so 
that bogus columns due to excessive colspans either (1) get no allocation (like 
IE, I think) or (2) they get a minimal amount (like Nav). 

Jonas, Can you explain the problem with the url which led you to develop the 
test case. Thanks.

Comment 3

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

1. Go to http://www.altavista.com
2. Make your mozilla window approx 1000px wide.
3. Watch the banner ad
4. Slowly decrease the width of the window

When the browser is approx 800px wide the banner will make a jump.

One interesting thing is that neither Mozilla or WinIE5 makes the table width 
in the testcase 100%.


The CSS2 spec dosn't mention how this should be handeled but the HTML4 spec 
says that the table should contain 3 columns. Mozilla seems to differ in 
behavouir between <td colspan=3> and <td><td><td> when calculating the number 
of columns shown which is wrong.

I think that the best and easiest way to handle this is to add an extra 
anonymous table cell at the end of the first row. The cell should have
"exmpty-cells:hide". This could be done in all cases when cells don't add up to 
a full matrix. (should I file that as a seperat bug?)

Comment 4

[karnaze (gone)]

Marking mozilla0.8.

Comment 5

[karnaze (gone)]

Attachment: patch to fix the bug

Comment 6

[karnaze (gone)]

I think it is better to handle over specified colspans (at the end of the 
table) the way IE does and drop off the columns that have no originating cells. 
This is what recent changes to table code have done. The attached patch fixes a 
problem introduced by the new code when viewing the 1st attachment.

Comment 7

[buster]

sr=buster

Comment 8

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

I think it's wrong to differ between <td colspan=3> and <td><td><td>. IMO it's 
better to *always* add extra ananymous cells to fill up to an entire matrix, 
then to in some cases try to be "intelligent" and remove/shrink cells.

Comment 9

[Asa Dotzler [:asa]]

can this be checked in soon?  It would be nice to have one less crasher in
Mozilla 0.7 :)
-Asa

Comment 10

[karnaze (gone)]

The patch was checked in.

Comment 11

[Bernd]

Attachment: how the testcase should render

Comment 12

[Bernd]

Attachment: how the testcase should not render

Comment 13

[Bernd]

Attachment: how the testcase should render

Comment 14

[Bernd]

Attachment: correct testcase look third attempt

Comment 15

[Bernd]

The testcase has regressed due to checkin for bug 46623. I think it should be
urgently fixed. 

Comment 16

[karnaze (gone)]

Moving to mozilla0.8.1

Comment 17

[Bernd]

i will take this one

Comment 18

[Bernd]

Attachment: patch

Comment 19

[Bernd]

finally I got the stuff throught the regression tests. The following regression
tests failed:
other/misc.html
bugs/bug1188.html
bugs/bug8858.html
bugs/bug60807.html
bugs/bug42443.html

misc.html and bug1188.html are identical and correctly rendered, so the failure
is caused by internal row redistribution. The same is true for bug8858.html.
bug60807.html significantly improves while it is not absolutely perfect. I think
I have thorougly tested the patch. ( I found several other regressions, down to
a topcrash.)

Comment 20

[Marc Attinasi]

[s]r=attinasi

Comment 21

[Bernd]

fix checked in

Comment 22

[Amarendra Hanumanula]

QA contact update

Comment 23

[Amarendra Hanumanula]

 This was fixed.. The table gets resized with the window resize.. Verified on 
2001-07-27-00-0.9.2 build.. Marking verified