Closed
Bug 490643
Opened 16 years ago
Closed 8 years ago
Using a cell with width=100% to force a table to maximum size, does not work when the cell has colspan=3
Categories
(Core :: Layout: Tables, defect)
Core
Layout: Tables
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: happy_melon, Unassigned)
References
()
Details
(Keywords: regression, testcase)
Attachments
(4 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 By defining a table's width in terms of its margins, and using a cell with explicit width=100% to force it to those margins, you can create a table that never overlaps other objects: <table style="margin:0 10%"> <tr> <td style="width:1px;"><!--More than one cell is needed--></td> <td style="width:100%">Something to put into the table</td> </tr> </table> If for some reason you needed to give the 'forcing' cell a colspan, it usually works, but not if the colspan is *exactly* three. So 1, 2, 4, 5, etc (at least those numbers) work perfectly. Reproducible: Always Steps to Reproduce: <html> <style type="text/css"> <!-- .tmbox { margin: 2px 10%; border: 1px solid #000000; } .mbox-text { width: 100%; } --> </style> <body> <table class="tmbox"><tr> <td style="width:1px;"></td> <td class="mbox-text" colspan="1">colspan="1"</td> </tr></table> <table class="tmbox"><tr> <td style="width:1px;"></td> <td class="mbox-text" colspan="2">colspan="2"</td> </tr></table> <table class="tmbox"><tr> <td style="width:1px;"></td> <td class="mbox-text" colspan="3">colspan="3"</td> </tr></table> <table class="tmbox"><tr> <td style="width:1px;"></td> <td class="mbox-text" colspan="4">colspan="4"</td> </tr></table> <table class="tmbox"><tr> <td style="width:1px;"></td> <td class="mbox-text" colspan="5">colspan="5"</td> </tr></table> </body> </html> Actual Results: All the tables are 80% width, except for the one with colspan=3, which is the minimum width required to display the text on one line. Expected Results: All the tables should be 80% width
Updated•16 years ago
|
Component: General → Layout: Tables
Product: Firefox → Core
QA Contact: general → layout.tables
Comment 1•16 years ago
|
||
(In reply to comment #0) > <table style="margin:0 10%"> Could you post these testcases as attachments on this bug (via the "Add an attachment" link), rather than inline HTML in a comment?
Comment 3•16 years ago
|
||
The tables in the attached testcase all look identical to me... From Comment 0's "Actual Results" section, it sounds like the colspan=3 table is purportedly too skinny, but it looks the same as the rest to me. (using Linux + Firefox 3.0.10 and also a mozilla-central nightly)
Comment 4•16 years ago
|
||
Regression range is http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1171826520&maxdate=1171829399
Keywords: regression,
testcase
Comment 5•16 years ago
|
||
Well, that range strongly points to bug 366865; however, I'm still unclear on how to see the bug here, per comment 3. What am I missing?
Blocks: 366865
Comment 6•16 years ago
|
||
Comment 8•16 years ago
|
||
Thanks Ria -- that's odd, this is WFM using Firefox 3.0.10 on Linux, as shown in this screenshot. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.10) Gecko/2009042523 Ubuntu/9.04 (jaunty) Firefox/3.0.10 I guess this bug is windows-only?
Updated•16 years ago
|
Attachment #375089 -
Attachment description: How the testcase looks here → screenshot of buggy behavior, on Windows
Updated•16 years ago
|
Attachment #375090 -
Attachment description: screenshot of correct behavior from testcase, on Linux → screenshot of correct behavior, on Linux
Updated•16 years ago
|
OS: All → Windows Vista
Comment 9•16 years ago
|
||
Is this bug in mozilla-central nightlies, too (on Windows)? http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
Comment 10•16 years ago
|
||
(In reply to comment #9) > Is this bug in mozilla-central nightlies, too (on Windows)? > http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ Yes Daniel.
Updated•16 years ago
|
Version: unspecified → Trunk
Comment 11•16 years ago
|
||
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b5pre) Gecko/20090427 Shiretoko/3.5b5pre Broken for me on Mac.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 12•16 years ago
|
||
Thanks Ria & Bret -- I guess this is broken on everything-but-linux. Setting OS back to all. (BTW, I confirmed that it's WFM on David Dahl's Ubuntu machine, too, so it's not *just* me :))
OS: Windows Vista → All
Comment 14•16 years ago
|
||
http://mxr.mozilla.org/mozilla-central/source/layout/tables/BasicTableLayoutStrategy.cpp#460 is part of the problem 460 if (pct_total == 1.0f) { 461 if (nonpct_pref_total > 0) { 462 pref_pct_expand = nscoord_MAX; 463 // XXX Or should I use some smaller value? (Test this using 464 // nested tables!) 465 } 466 } The division by 3 causes rounding errors so we end here with 0.9999994 in the colspan 3 case
Comment 15•16 years ago
|
||
Please feel free to take this, convert it into a decent patch with a reftest and try to get it reviewed. I have now a patch which is already idling for two months in the review queue without a single comment (see bug 478614) I am just too demotivated to work on this.
Reporter | ||
Comment 17•16 years ago
|
||
I know exactly what you mean. I spend most of my time floating around the MediaWiki bugzilla, which is even more annoying: first you wait for a month for anyone to even notice, then you actually *get* good reviews that help you tidy up your patch, then someone says "looks great" **and then leaves it**... I have a patch to paginate a table that's huge enough to time out browsers on anything less than a blistering connection, that's been sitting around for a month yesterday, *after* being reviewed. Grrr.... Anyway, Mozilla isn't really my thing (I don't even know what language you write in; looks like C?); anyone who stumbles across this, do feel free to take it as Bernd says. At least it's also broken on IE... :-D
Firefox: 46.0.1, Build ID: 20160502172042 User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0 I have tested this issue on the latest Firefox (46.0.1) release, latest Nightly (49.0a1 - Build ID: 20160601061753) build, and is no longer reproducible. All the tables have the same width. I can confirm that this issue was reproducible on an older version of Firefox (v 3.0). Considering this I will mark this issue as Resolved - WFM. If anyone still encounters this issue, please feel free to reopen this or file a new one.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
Comment 19•8 years ago
|
||
I just checked the testcase from bug 496315, which was marked a duplicate of this issue. That one still shows the incorrect behavior. See: https://bugzilla.mozilla.org/attachment.cgi?id=381513 So the patch did not fix everything or the bug was not a duplicate of this one.
See Also: → 496315
You need to log in
before you can comment on or make changes to this bug.
Description
•