Table height restriction in Composer

VERIFIED FIXED in mozilla1.2alpha

Status

VERIFIED FIXED
16 years ago
14 years ago

People

(Reporter: d_king, Assigned: cmanske)

Tracking

Trunk
mozilla1.2alpha

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

16 years ago
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

16 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

16 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

16 years ago
I refer you to Bug #154588 for an answer to your question.
(Assignee)

Comment 4

16 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

16 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

16 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)
URL: N/A
OS: Windows 98 → All
Hardware: PC → All
(Reporter)

Comment 7

16 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

16 years ago
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.
(Assignee)

Updated

16 years ago
Keywords: nsbeta1, patch, review
Whiteboard: [FIX IN HAND] need r=,sr=

Comment 9

16 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

16 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

16 years ago
Keywords: nsbeta1 → nsbeta1+
(Assignee)

Comment 11

16 years ago
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.
(Assignee)

Updated

16 years ago
Blocks: 144254

Comment 12

16 years ago
Comment on attachment 95449 [details] [diff] [review]
patch v1

r=brade
Attachment #95449 - Flags: review+

Comment 13

16 years ago
Comment on attachment 95449 [details] [diff] [review]
patch v1

sr=hewitt
Attachment #95449 - Flags: superreview+
(Assignee)

Comment 14

16 years ago
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
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.