Open Bug 444842 Opened 15 years ago Updated 4 months ago

table cells with colspan bigger than 1000 are collapsed

Categories

(Core :: Layout: Tables, defect)

PowerPC
macOS
defect

Tracking

()

People

(Reporter: ambiguo123, Unassigned)

Details

(Keywords: testcase)

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; it; rv:1.9) Gecko/2008061004 Firefox/3.0
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; it; rv:1.9) Gecko/2008061004 Firefox/3.0

If a cell has colspan > 1000, it is rendered like it had colspan 1. Even firebug says 'colspan="1"'.
I flagged this as a minor bug because i understand it is not common to work with a table so huge, but I actually need such a colspan. On Safari it works fine, and the w3c standard do not set any limit to colspan, so I think it IS a bug, actually.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.



As far as I know, this colspan limit exists also in FF2.
Component: General → Layout: Tables
Product: Firefox → Core
QA Contact: general → layout.tables
Attached file testcase
http://hg.mozilla.org/mozilla-central/index.cgi/annotate/2dda8388dd0c/content/html/content/src/nsHTMLTableCellElement.cpp#l265

Can our data structures deal with larger colspans, or is the limit necessary given the current implementation?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: testcase
Bug 443089 suggests to me that our data structures can't deal.  cf bug 348954.
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/content/html/content/src/nsHTMLTableCellElement.cpp&rev=1.112&mark=264,265#250
man that hgblame is so lame  with a normal blame one would easily see bug 141818 as the reference. ==> WONTFIX
The fact that Safari can handle it suggests to me that we might be able to handle it with a better data structure...
I don't see any use case for this other than exploits.
indeed a human should not be able to use a table of more than 1000 columns, but I as the developer do not know on which tables the users will test my component. (the component has also a "transpose x and y axes" button - I stumbled upon this bug using that button on a table of 1100 rows. Not an impossible event I believe.)
IE7 seems to do exactly the same as Mozilla here.
;-) IE6 too, you know reverse engineer is my second name 
I have the same problem.. in IE7 the my table look great.
I use infinit colspan...
If you're using infinite colspan (colspan="-1"), I think you're hitting a different bug (not this one).
No.. infinity with php.. I'm calculate the right colspan of the table... normaly have more of 1000

(In reply to comment #11)
> If you're using infinite colspan (colspan="-1"), I think you're hitting a
> different bug (not this one).
I have big difficulties to see that comments 10 and 12 are about this bug. Martijn also did see something different.
(I originally commented in the Bug 321474, but I noticed it was closed)

I am aware of the original Bug 141818 that is the cause for this. Yet, in a newer Bug 688405, a similar rowspan limitation was raised.

Chrome is fine with colspan > 1000.

Use case: Pivot table. And I think with the amount of data we have, this limitation will be hit more and more often.
This is by all means an annoying bug. Other browsers cope fine with this.

Tables are useful for so many things. I use them to display GANT tables/schedules and project plans. Using colspan I can very effectively place activities and their duration on a horizontal timescale, while using rows for parallell activities.

At least allowing 1920 or 2560 columns would make a worthwhile improvement for screen rendering of such tables.
Alreayd in 2017 and the bug still remains!!!
Severity: minor → S4
You need to log in before you can comment on or make changes to this bug.