textarea 1 one more character than specified width & height

VERIFIED FIXED

Status

()

Core
Layout: Form Controls
P3
major
VERIFIED FIXED
19 years ago
19 years ago

People

(Reporter: Brade, Assigned: rods (gone))

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [TESTCASE])

Attachments

(2 attachments)

(Reporter)

Description

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

Comment 1

19 years ago
Created attachment 312 [details]
html example which exhibits bug

Updated

19 years ago
Assignee: karnaze → pollmann

Comment 2

19 years ago
Reassigning to Eric.

Updated

19 years ago
Status: NEW → ASSIGNED

Comment 3

19 years ago
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.

Updated

19 years ago
Whiteboard: [TESTCASE]

Comment 4

19 years ago
Simplest possible testcase already attached. Marking as [TESTCASE]...

Comment 5

19 years ago
Created attachment 2157 [details]
Comparison of textarea controls with and without scrollbars

Comment 6

19 years ago
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?

Updated

19 years ago
Assignee: pollmann → rods
Status: ASSIGNED → NEW
OS: Mac System 8.5 → All
Hardware: Macintosh → All
Target Milestone: M13

Comment 7

19 years ago
Another old size bug...

Comment 8

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

Updated

19 years ago
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 9

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

Updated

19 years ago
Depends on: 17408

Comment 10

19 years ago
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).

Updated

19 years ago
QA Contact: phillip → chrisd

Updated

19 years ago
Whiteboard: [TESTCASE] → [TESTCASE]12/1/99: pending clarification from assigned eng prior to verification

Comment 11

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

19 years ago
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).

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 13

19 years ago
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.

Updated

19 years ago
Whiteboard: [TESTCASE]12/1/99: pending clarification from assigned eng prior to verification → [TESTCASE]
You need to log in before you can comment on or make changes to this bug.