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)

defect
Not set
normal

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
Component: General → Layout: Tables
Product: Firefox → Core
QA Contact: general → layout.tables
(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?
Attached file testcase
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)
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
And "here" is on Windows XP/Vista, sorry.
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?
Attachment #375089 - Attachment description: How the testcase looks here → screenshot of buggy behavior, on Windows
Attachment #375090 - Attachment description: screenshot of correct behavior from testcase, on Linux → screenshot of correct behavior, on Linux
OS: All → Windows Vista
Is this bug in mozilla-central nightlies, too (on Windows)?
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
(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.
Version: unspecified → Trunk
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
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
I see this in my debug build so it should be fairly easy ;-)
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
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.
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
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.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: