Last Comment Bug 194024 - Table cell not calculated correctly if cellpadding=0 and border=(0 or undefined)
: Table cell not calculated correctly if cellpadding=0 and border=(0 or undefined)
Status: VERIFIED FIXED
: testcase
Product: Core
Classification: Components
Component: Layout: Tables (show other bugs)
: Trunk
: All All
: P2 normal (vote)
: Future
Assigned To: Bernd
: Madhur Bhatia
Mentors:
http://homepage.mac.com/matias/bugs/b...
: 199526 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2003-02-19 05:19 PST by Matias Larsson
Modified: 2003-06-04 16:53 PDT (History)
3 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase ... with <table border="0"> (519 bytes, text/html)
2003-02-19 14:39 PST, Madhur Bhatia
no flags Details
testcase ..... with <table border="1"> (519 bytes, text/html)
2003-02-19 14:41 PST, Madhur Bhatia
no flags Details
testcase - showing cellpadding problem (2.34 KB, text/html)
2003-03-07 11:38 PST, Daniel Wang
no flags Details
patch (1011 bytes, patch)
2003-03-29 01:56 PST, Bernd
john: review+
bzbarsky: superreview+
Details | Diff | Splinter Review

Description Matias Larsson 2003-02-19 05:19:07 PST
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20021220 Chimera/0.6+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20021220 Chimera/0.6+

The first example will render with too wide td's. (the green stuff) The second
(the only change being border="1") will render as expected.

If you swap the textarea for a 100% wide div, it works as expected too, so I'm
not sure where this problem lies.

The rendering problem occurs in 1.3b, Chimera (Moz1.0) on both Mac and PC

Reproducible: Always

Steps to Reproduce:
1.Click on the provided URL ( http://homepage.mac.com/matias/bugs/bug.html )
2.Look at the first example
3.Look at the second example (which works as expected)

Actual Results:  
The outer table renders with too wide td's

Expected Results:  
Render it with td's with a witdh of 12px each (give or take a couple of pixels)
Comment 1 Boris Zbarsky [:bz] 2003-02-19 07:25:38 PST
Seeing this with current trunk linux builds too...
Comment 2 Madhur Bhatia 2003-02-19 14:34:41 PST
see this on winXP as well. I checked this on 1.2beta, 1.3 alpha and 1.3 beta.
All render the table width incorrectly for the first testcase.

IE renders the table width fine. 
Comment 3 Madhur Bhatia 2003-02-19 14:39:13 PST
Created attachment 114927 [details]
testcase ... with <table border="0">

reporter's 1st testcase provided as a bugzilla attachment (shows the bug)
Comment 4 Madhur Bhatia 2003-02-19 14:41:11 PST
Created attachment 114928 [details]
testcase ..... with <table border="1">

reporter's 2nd testcase provided as a bugzilla attachment. (renders correctly)
Comment 5 Daniel Wang 2003-03-07 11:38:18 PST
Created attachment 116574 [details]
testcase - showing cellpadding problem

Cell width is not calculated correctly if cellpadding=0 and border=0/undefined
Comment 7 Bernd 2003-03-29 01:56:16 PST
Created attachment 118849 [details] [diff] [review]
patch

The problem here IMHO is that auto cells that contain only percentage based
childs will still have a non zero desired width but can have a zero min-, fix-
and pct width. Before checkin 201 we tried to avoid to assign widths to bogus
columns at the end, this happens when a colspan at the end spans columns that
are not populated with cells on other rows. Checkin 201 changed that behaviour
trying to avoid to give widths to columns that contain empty cells like a
<td></td>. As soon as the table cells have a padding or a border there minimum
content width is > 0 and the situation will be as before the checkin. The
attached patch expands that mechanism also to columns with a nonzero desired
width. To go further with this patch I would need access to testcases that the
checkin 201 tried to fix.
Comment 8 Bernd 2003-03-29 02:06:22 PST
*** Bug 199526 has been marked as a duplicate of this bug. ***
Comment 9 Bernd 2003-04-07 08:48:34 PDT
mine
Comment 10 John Keiser (jkeiser) 2003-04-07 11:20:16 PDT
Comment on attachment 118849 [details] [diff] [review]
patch

You don't need to check GetMinWidth() or GetFixWidth() anymore, because desired
width will always be bigger than either of them.  Maybe the others too, but
those two are the obvious ones I can see.

The change is a good one though.  Racking my brain I can't think of things this
would fail on (because of the fact that we checked min width before already). 
Make darn sure this one goes through the regression tests though, please.
Comment 11 Bernd 2003-05-31 07:23:22 PDT
fix and testcase checked in
Comment 12 Daniel Wang 2003-06-04 16:53:06 PDT
v

Note You need to log in before you can comment on or make changes to this bug.