From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1a+) Gecko/20020628 BuildID: 2002062804-TRUNK Within Composer, I cannot set <td height=XXX> to be greater than 10,000. Why is this? Reproducible: Always Steps to Reproduce: 1. Create a table in Composer 2. Try to set one of the cells to have a height greater than 10,000 pixels . Actual Results: Error message. Expected Results: To increase table height.
-->cmanske workaround--can you set height by css instead? If so, does that also impose a limit?
Assignee: syd → cmanske
We need to have some limit. Yes, the 10,000 is arbitrary, but why would you ever want anything larger!
I refer you to Bug #154588 for an answer to your question.
Wow! I see no reason to not expand the limit -- how about 100,000? Brade?
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.2alpha
There is always an exception to the rule....it's one of the problems with programming for users. Is it possible to not have a limit? Or at least, the limit is defined by (excuse my bad C skills) a "doubleint" (or is that "long int")?
I agree with comment 5; there really is a limit but we may not know what it is (and perhaps it is limited on one platform before another?). Also, there is the issue of performance (probably not an issue here but I'd have to do some testing to be sure); I don't want to allow users to create tables so high that the table takes forever to render and they think that the software hung. Also, I doubt most users really want to make a table more than 10,000 high. Perhaps they can do that in html source but not in the dialog? (we'd have to ensure that they could change it in the dialog if the value came in above our limit but not force them to lower it)
OS: Windows 98 → All
Hardware: PC → All
OK, if increasing the limit in Composer will cause performance problems, then I will accept that. However, and I realise this has nothing to do with Composer, there is still the issue with Bug #154588. Brade, if you find that increasing the limit will cause performace problems, then feel free to close this bug as "WONTFIX".
Created attachment 94275 [details] [diff] [review] patch v1 I don't think the performance problem should overly-influence the upper limit. Table with just a few columns and 10000 rows (or vice versa) are tolerable. I favor using 10000 as the upper limit.
Keywords: nsbeta1, patch, review
Whiteboard: [FIX IN HAND] need r=,sr=
What about the issue of row/colspan? Does Gecko have a limit (as the existing comment states)? Here is the comment I am referring to: // This is the value gecko code uses for maximum rowspan, colspan What happens if you create a table with 2x2000 cells wide and select a row and make it span? Does it crash? Does it fail to work? Does the html get messed up?
Comment on attachment 94275 [details] [diff] [review] patch v1 oops! This bug is getting confused with bug 144254, which is about increasing limit on number of rows, not the *height*.
Attachment #94275 - Attachment is obsolete: true
Created attachment 95449 [details] [diff] [review] patch v1 New upper limits determined by testing layout performance. This patch puts all limits in the shared EdDialogCommon.js and thus fixes inconsistency in table limits noted in bug 144254.
Comment on attachment 95449 [details] [diff] [review] patch v1 r=brade
Attachment #95449 - Flags: review+
Comment on attachment 95449 [details] [diff] [review] patch v1 sr=hewitt
Attachment #95449 - Flags: superreview+
checked into 1.2 trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
Whiteboard: [FIX IN HAND] need r=,sr=
yep, got an error when i tried to enter 1000001 pixels. vrfy'd fixed with 2003.02.19 on linux rh8.0.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.