7461 - textarea 1 one more character than specified width & height

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect, P3)

Description

[Kathleen :Brade]

in an html file, <textarea rows="4" cols="10"> allows the user to get 11
characters across and is 5 rows high

Comment 1

[Kathleen :Brade]

Attachment: html example which exhibits bug

Comment 2

[karnaze (gone)]

Reassigning to Eric.

Comment 3

[leger]

Moving all Widget Set bugs, past and present, to new HTML Form Controls
component per request from karnaze.  Widget Set component will be retired
shortly.

Comment 4

[Aaron Swartz]

Simplest possible testcase already attached. Marking as [TESTCASE]...

Comment 5

[Sean Richardson]

Attachment: Comparison of textarea controls with and without scrollbars

Comment 6

[Sean Richardson]

Comments:

First, M11 build 1999101216 on WinNT displays the same behaviour.
Likely crossplatform.

Second, the textarea controls seem well sized iff the horizontal and
vertical scrollbars are present - see the 10/13/99 attachment.

Suggest a decision be made among three courses of action,
presented in descending order of desirability and 4.x parity:
1. Paint the scrollbars on all textareas from the beginning.
2. Paint the scrollbars on textareas only as required (Current behaviour).
3. Size the textarea control initially just big enough for the cols and rows,
and then resize it later if needed to make room for one or both scrollbars.

1. is the Nav 4.x behaviour
2. would take no work other than making this bug INVALID
3. seems just too complex and HTML-author-unfriendly

The only complication: the WRAP attribute. Would there be any
reason to initialize a textarea control's visual size based on
the value of the WRAP attribute?
Note that this attribute does not appear in REC-html40:
( http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.7 )

Third, Nav 4.7 blanks the top few pixels of the rows+1 row that would
otherwise appear in the textarea. M11 to date doesn't. Is this worth
creating a new bug report for?

Comment 7

[Eric Pollmann]

Another old size bug...

Comment 8

[Sean Richardson]

Testing with 1999-10-18-08-M11 on Windows NT 4.0sp3,
with GFX TEXTAREA scrollbars turned on rather than native scrollbars,
the 10/13/99 testcase looks otherwise the same as before:

The TEXTAREA looks bigger than it is defined to be, until enough
content is entered to force the scrollbars to appear, at which point
it looks correct. See the 10/13/99 comments for details.

Comment 9

[rods (gone)]

Scrollbars are turned on now and the sizing is correct - fixed

Comment 10

[Sean Richardson]

The FIX for this bug is mutually incompatible with fixing bug 16936 -
either the scrollbars appear initially or they don't!

Suggest either REOPENing due to the regression described in bug 17408,
or marking WONTFIX due to the issue mentioned in bug 16936 - quoting:
"Because of the way Gecko handles scrollbars (meaning both are either on or both
are only visible when needed) it will be impossible to have them displayed
exactly like Nav. So best we can do is not have them displayed until they are
needed. "

The other option is to add code to Gecko to support the Nav 4 behaviour
(best option IMHO, but the most work).

Comment 11

[Christine Hoffman]

Rod - I need a clarification on this one. Using 12/1 build on Win 95 with the
original testcase, a horizontal scrollbar is generated (not needed) but not a
vertical scrollbar. Should I expect to see both scrollbars initially, or should
I see scrollbars as needed? I see neither option at this point.

Comment 12

[Sean Richardson]

The work for bug 12825 seems very relevant for this bug. Briefly, at present
the only way to create a scrolling view (of any kind) with no scrollbars is to
create the view with the scrollbar(s) and then hide them, which can cause
problems with sizing being wrong by the size of the scrollbars.

Quoting from bug 12825:
>The style system needs to be modified so we can independently hide the
>horizontal scrollbar, the vertical scrollbar, or both, but still be able
>to scroll the view.

With this in place, it should be possible to default to the Nav 4.x behaviour
of a greyed vertical scrollbar and no horizontal scrollbar initially,
so long as the scroll property is unset or set to auto (see bug 16936 from
11/08/99 to present for discussion of that).

Comment 13

[Christine Hoffman]

After discussing bug with Rod, I am verifying it fixed regarding the original
problem which was that the textarea was too large. A text area now contains the
correct area according to specification. The scrollbar issue should be another
bug.