Closed
Bug 155193
Opened 22 years ago
Closed 22 years ago
Table height restriction in Composer
Categories
(SeaMonkey :: Composer, defect)
SeaMonkey
Composer
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla1.2alpha
People
(Reporter: d_king, Assigned: cmanske)
References
Details
Attachments
(1 file, 1 obsolete file)
11.20 KB,
patch
|
Brade
:
review+
hewitt
:
superreview+
|
Details | Diff | Splinter Review |
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.
Comment 1•22 years ago
|
||
-->cmanske workaround--can you set height by css instead? If so, does that also impose a limit?
Assignee: syd → cmanske
Assignee | ||
Comment 2•22 years ago
|
||
We need to have some limit. Yes, the 10,000 is arbitrary, but why would you ever want anything larger!
Reporter | ||
Comment 3•22 years ago
|
||
I refer you to Bug #154588 for an answer to your question.
Assignee | ||
Comment 4•22 years ago
|
||
Wow! I see no reason to not expand the limit -- how about 100,000? Brade?
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.2alpha
Reporter | ||
Comment 5•22 years ago
|
||
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")?
Comment 6•22 years ago
|
||
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)
Reporter | ||
Comment 7•22 years ago
|
||
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".
Assignee | ||
Comment 8•22 years ago
|
||
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.
Assignee | ||
Updated•22 years ago
|
Comment 9•22 years ago
|
||
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?
Assignee | ||
Comment 10•22 years ago
|
||
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
Assignee | ||
Updated•22 years ago
|
Assignee | ||
Comment 11•22 years ago
|
||
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 12•22 years ago
|
||
Comment on attachment 95449 [details] [diff] [review] patch v1 r=brade
Attachment #95449 -
Flags: review+
Comment 13•22 years ago
|
||
Comment on attachment 95449 [details] [diff] [review] patch v1 sr=hewitt
Attachment #95449 -
Flags: superreview+
Assignee | ||
Comment 14•22 years ago
|
||
checked into 1.2 trunk.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Whiteboard: [FIX IN HAND] need r=,sr=
Comment 15•21 years ago
|
||
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
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•