TEXTAREA: no scroll bar until 1st character is typed.

RESOLVED WORKSFORME

Status

()

Core
Layout: Form Controls
P5
minor
RESOLVED WORKSFORME
17 years ago
7 years ago

People

(Reporter: Brad Garcia, Assigned: kinmoz)

Tracking

({polish, testcase})

Trunk
Future
x86
Linux
polish, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
I will be attaching a testcase.

I have a page with a number of <INPUT TYPE="text" SIZE=60> and
<TEXTAREA COLS=60> fields in it.

At first glance, it looks like the TEXTAREAS are longer than the INPUT
sections, even though the width should be the same.

Then, as soon as I type 1 character into the TEXTAREA, a scrollbar appears
on the right hand side, covering up the part that made the TEXTAREA
appear larger.

This is pretty minor, but should probably be fixed in one of two ways:

1) Have the scrollbar always appear.
2) Have the "boxed" region not include the scrollbar, and have the scrollbar
   appear just to the right of the boxed region.
(Reporter)

Updated

17 years ago
Keywords: polish
(Reporter)

Comment 1

17 years ago
Created attachment 27815 [details]
Shows TEXTAREA behavior described above.

Comment 2

17 years ago
reassigning
Assignee: rods → beppe

Comment 3

17 years ago
First, the rows attribute is required, even if the value is set to 1, see:
http://www.w3.org/TR/html4/interact/forms.html#edef-TEXTAREA

Kin and I found this bug while debugging this one. See bug 72127. If you specify 
"style: scroll" then vertical sb never appears if row=1, if you specify "style: 
auto", then the vertical sb only disappears if the horz scrollbar appears. 
Whenever there is a horz scrollbar and row=1 the vert sb disappears, bottomline 
it really doesn't matter what the overflow is set to, if those conditions are 
met. This issue is being assigned to evaughan, who owns scrollbars.

Second, for the scrollbars to appear as the default, the default style needs to 
be overflow: scroll, currently it is set to auto. That would be rods code. 
Reassigning back to rod for disposition of the default value
Assignee: beppe → rods
Priority: -- → P5
Target Milestone: --- → Future

Comment 4

17 years ago
Confirmed on linux: 2001032908
Marking as NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 5

17 years ago
reassiging
Assignee: rods → beppe

Comment 6

17 years ago
rod -- did you fix your part of this problem or are you just reassigning because 
you want editor folks to fix your code?
Assignee: beppe → rods

Comment 7

17 years ago
The overall size of the textarea is NOT getting larger, sizing and submission 
are our only responsibily for the text field/area.

If you were to go to line:
http://lxr.mozilla.org/mozilla/source/layout/html/forms/src/nsGfxTextControlFram
e2.cpp#1805

you would see that the scroll values are hard coded in the 
"CreateAnonymousContent" which has nothing to do with sizing or submission. You 
would also find that hyatt was the last to touch the code. I think this goes 
back to where Hyatt and Kin were working on trying to get just the vertical 
scroll to show in some cases, but I don't remember that level of detail about 
what they were doing. Sending the bug back to you, so you can reassign it to Kin 
or Hyatt.

When scrollbars appear and how they effect the internal size of the "typing" 
content area is not part of the code I am responsible for, if you think it is 
talk to Kevin.
Assignee: rods → beppe

Comment 8

17 years ago
-->kin
Assignee: beppe → kin
(Reporter)

Comment 9

17 years ago
linux x86 2001-09-30-21

Behavior is a little different now.
Now the scrollbar only appears when the number of lines of
text typed exceeds the rows of the testarea.

But the other issue still exists.  The textarea is larger
than an "input type=text" box of the same size (until the
scrollbar appears).
Proper component
Component: Form Submission → HTML Form Controls

Comment 11

16 years ago
See also bug 82160.
The reason for the change in behavior in comment 9 was the checkin of bug 91794
on 2001-08-23.  See bug 64807.

Comment 13

16 years ago
To demonstrate a further problem:

Type an extra line of text so the textarea scrolls down and the scroll bar appears.
Delete the extra line of text so it would fit in the text area.

At this point the scroll bar is removed even though the text still scrolled off
the top.

Either the scroll bar should stay as long as the text is scrolled or the text
should automatically scroll back down when it fits allowing the scroll bar to be
removed.  Netscape uses the latter approach though it just disables rather than
removes the scroll bar.

Updated

15 years ago
Keywords: testcase
QA Contact: vladimire → layout.form-controls
No scrollbar appears on 3.6 and trunk.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.