in an html file, <textarea rows="4" cols="10"> allows the user to get 11 characters across and is 5 rows high
Reassigning to Eric.
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.
Simplest possible testcase already attached. Marking as [TESTCASE]...
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?
Assignee: pollmann → rods
Status: ASSIGNED → NEW
OS: Mac System 8.5 → All
Hardware: Macintosh → All
Target Milestone: M13
Another old size bug...
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.
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
Scrollbars are turned on now and the sizing is correct - fixed
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).
Whiteboard: [TESTCASE] → [TESTCASE]12/1/99: pending clarification from assigned eng prior to verification
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.
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).
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.
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.