32841 - Colspans with large min width don't honor proportional cols

Status: RESOLVED WONTFIX

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

Description

[hysteros]

Hi.

On the Websites http://www.cityweb.de, the HTML-Tables are showed in a
wrong layout. At the top, the table is too big, in the middle right, at
bottom too big. The correct layout can be viewed with Netscape 4.0 or
IE 4.
The Bug exists in M12, M13, M14 on all platforms.

Comment 1

[Gervase Markham [:gerv]]

[e-mail] - are you still seeing this problem on recent builds of 
Mozilla?

Gerv

Comment 2

[Gervase Markham [:gerv]]

Yep, it's still there. Confirming using M15 (20000418) on W95. Needs a 
testcase...

Gerv

Comment 3

[Tim Stallmann]

making a test case.. looks like this one will be tricky.

Comment 4

[Gervase Markham [:gerv]]

Tim Stallman - any luck with your test case?

Gerv

Comment 5

[Gervase Markham [:gerv]]

Removing makingtest to add this bug back into the BugAThon. It's still there 
with 2000-05-27 W95.

Gerv

Comment 6

[cheng]

I managed to get the page to format correctly if I remove the <IFRAME> in the
top table, and the <COLGROUP> in the bottom table.  According to
http://www.willcam.com/cmat/html/crossref.html, neither of these tags are
supported by Netscape nor W3C.  Should this be marked invalid?

Comment 7

[Mats Palmgren (inactive)]

The problem seems to be a conflict between the width specified in the COL
elements and the actual width of the content in the cells. I have distilled
http://www.cityweb.de down to a bare minimum as a testcase.

Comment 8

[Mats Palmgren (inactive)]

Attachment: Testcase

Comment 9

[Bernd]

The testcase triggers the assertion at line 276 of BasicTableLayoutStrategy.cpp

Comment 10

[Bernd]

Attachment: reduced testcase

Comment 11

[Bernd]

snippet from the table dump:
The error occures inside  AssignNonPctColWidths -> colspanwidth
The width's should be at maximum 5025 and 2325 after this routine.

AssignNonPctColWidths en max=7350 count=0
***START TABLE DUMP***
mColWidths=0 0

 col frame cache ->
0=00BD2CEC 1=00BD2D54
 **START COL DUMP** colIndex=0 isAnonymous=0 constraint=0
  widths=-1 -1 -1 -1 -1 -1 -1 -1 -1  **END COL DUMP**
 **START COL DUMP** colIndex=1 isAnonymous=0 constraint=0
  widths=-1 -1 -1 -1 -1 -1 -1 -1 -1  **END COL DUMP**  ***END TABLE DUMP***
AssignNonPctColWidths ex
***START TABLE DUMP***
mColWidths=3585 3585

 col frame cache ->
0=00BD2CEC 1=00BD2D54
 **START COL DUMP** colIndex=0 isAnonymous=0 constraint=0
  widths=0 0 5025 3585 -1 -1 -1 -1 -1  **END COL DUMP**
 **START COL DUMP** colIndex=1 isAnonymous=0 constraint=0
  widths=0 0 2325 3585 -1 -1 -1 -1 -1  **END COL DUMP**  ***END TABLE DUMP***

Comment 12

[Mats Palmgren (inactive)]

WORKSFORME, 2000-12-27-05 on Windows 98 SE.
The original problem reported here (URL and 1st testcase) is now working.
There is still a 1-pixel round-off error at URL when resizing the window, but
that bug is reported elsewhere. The 2nd testcase only shows that <HR width=490>
is actually 488 pixels wide (try <img width=490 ...> instead and you will see
that the table width is correctly 490px).

I haven't checked if the assertion in BasicTableLayoutStrategy.cpp reported by
Bernd 2000-11-30 is still occuring.

Comment 13

[Bernd]

This bug is fixed on the surface, but underneath it is still buggy, the problem 
here is how the min con width of an auto width colspan is distributed to the 
table cells contained in the colspan, while the assertion is fixed, the 
tabledump is still buggy. I will attach a more selfexplaining testcase.

Comment 14

[Bernd]

Attachment: another testcase

Comment 15

[Bernd]

Attachment: next testcase with 3* and 1*

Comment 16

[Bernd]

Attachment: table dump for the second attachment

Comment 17

[karnaze (gone)]

Moving to m1.0

Comment 18

[Amarendra Hanumanula]

QA contact update

Comment 19

[Bernd]

Attachment: patch

Comment 20

[Bernd]

The patch fixes http://bugzilla.mozilla.org/showattachment.cgi?attach_id=21755
but does not fix http://bugzilla.mozilla.org/showattachment.cgi?attach_id=21756.
By this we are 100% compatible to IE6. ;-). The patch passes the regression tests.

Comment 21

[Marc Attinasi]

If karnaze thinks it is OK, then sr=attinasi (in other words, the code looks
fine, but I do not understand the full implications of the change to the table
code).

Comment 22

[karnaze (gone)]

r=karnaze. Bernd, it looks like you moved some code from one place to another.

Comment 23

[Bernd]

yes, I moved the code because we did not consider the col specified fixed width
for  the distribution of the min width. The patch is in. I am not closing the
bug as the proportional thing is still not working. Changing summary.

Comment 24

[Mats Palmgren (inactive)]

Some kind of regression has occurred since build 2000-12-27-05.
http://www.cityweb.de and 1st testcase (attachment 11760 [details]) is now broken again.

Comment 25

[karnaze (gone)]

-->m101

Comment 26

[karnaze (gone)]

mass reassign to default owner

Comment 27

[Bernd]

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

Comment 28

[j.j.]

http://bugzilla.mozilla.org/showattachment.cgi?attach_id=21755 and
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=21756 
wfm with
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20061231 Minefield/3.0a2pre

Comment 29

[Bernd]

the whole portional column stuff got removed