82160 - TEXTAREAs should always have a vertical scrollbar by default

Status: REOPENED

(Core :: Layout: Form Controls, defect)

Description

[Matthew T (active 1999-2002)]

Build: 2001052115, Mac OS 9.1

To reproduce:
*   Look at the right edge of the `Additional comments:' field in this bug
    report.

What you should see:
*   A disabled scrollbar.

What you actually see:
*   Nothing.

A textarea should always have a scrollbar, whether enabled or not, for two main
reasons. Firstly, it provides a valuable visual cue that what you're looking at
is a textarea, rather than just a white rectangle. And secondly, it avoids the
problem that the width of the textarea is dependent on the number of lines of
text in the textarea. In Mozilla currently, as soon as I enter more lines than
will fit in the displayed part of the textarea, the textarea gets two or three
characters narrower and all my lovely bulleted lists of steps to reproduce are
rewrapped to smithereens.

Comment 1

[James Green]

All/All. I can't believe we haven't filed this before.

Comment 2

[Eric Vaandering (no email)]

Strange. Under linux the scrollbar appears as soon as the first character is
typed. Sounds like on mpt's setup this isn't the case?

Comment 3

[Matthew T (active 1999-2002)]

The scrollbar should be present whether or not you've typed *any* characters. 
Currently on Mac OS it only appears once there is too much text to display all 
at once.

Comment 4

[Håkan Waara]

mpt, should it be both a vertical, disabled and a horizontal, disabled scrollbar?

Comment 5

[Matthew T (active 1999-2002)]

4.x has both. IE has just the vertical one. I think just the vertical one is 
necessary to stop the wrapping problem.

Comment 6

[timeless]

4.77win32 only has the vertical one. 

> it provides a valuable visual cue that what you're looking at
> is a textarea, rather than just a white rectangle.
Or it could be an <iframe>.

imo the rewrapping is a separate bug.

If it's possible for a text area to limit the user to X lines (where X is not 
greater than the number visible in the textarea) should we still display a 
scrollbar?

Comment 7

[Matthew T (active 1999-2002)]

I think IFRAMEs shouldn't have a vertical scrollbar by default, but top-level
BODYs should (that's bug 72540). Companion bugs to this one also need to be
filed for HTML listboxes and XUL listboxes.

I disagree that the rewrapping is a separate bug; if it was, then while you
didn't have a scrollbar you'd be wrapping ~20 pixels short of the edge of the
textarea, which would seem quite strange.

Comment 8

[rods (gone)]

I think this is a dup

Comment 9

[Matthew T (active 1999-2002)]

I just checked all open bugs in the HTML Form Controls component. This bug
doesn't appear to be a dup, though bug 72127 is somewhat similar.

Comment 10

[Miloslaw Smyk]

And what about bug #72101 ? Seems like dup.

Comment 11

[Phillip Oertel]

please ! don't add infunctional greyed-out scrollbars to _every_ damn textarea.
that only consumes space. when i got my first mozilla (M18) i was so happy to
see that it only displayed them when needed. very smart!

forms are the ugliest thing on the web for a designer. but mozilla has the most
beautiful form elements of all browsers. leave it like that.
at least leave the possibility open disable showing both scrollbars by default.
analog to frames that'd be (v-)scrolling='yes'/'no'/'auto'
let the designer decide how his textarea should look.

> as soon as I enter more lines than
> will fit in the displayed part of the textarea, the textarea gets two or three
> characters narrower and all my lovely bulleted lists of steps to reproduce are
> rewrapped to smithereens.
this shouldn't matter since the 'automatic' line wraps are 'virtual', they don't
 get transmitted to the CGI. so the script processing your text will format it
the way you intended it to look.

Comment 12

[James Green]

> this shouldn't matter since the 'automatic' line wraps are 'virtual', they
> don't get transmitted to the CGI. so the script processing your text will
> format it the way you intended it to look.

Er, no. Bugzilla displays comments as it received them, and as you can see in
this page's source, wrap is set to 'hard', thus wysisyg, making the re-wrap of
importance.

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Bug 64807 is about why our current behavior is different on Linux.

Comment 14

[puddy]

Always? ...This is close to saying that EVERY link needs to be blue and
underlined. designers need to beable to control the overflow of any element that
has "overflow". We need to give the designer the upperhand here, if anything,
take the IE5 approach... scrollbars are there by default but overflow:auto takes
them out till they are needed. Personally, I like it the way it is now.

Comment 15

[Sterling Bates]

When viewed on an active matrix laptop screen it is extremely difficult to see 
the right and bottom bounds of the textarea (it looks like a bevel).  If the 
disabled scrollbar isn't placed there, may I suggest we darken the colors 
slightly.

Comment 16

[Matthew T (active 1999-2002)]

Resummarizing to make puddy happy. Yes, this should be overridable using CSS.

Comment 17

[Peter Trudelle]

Isn't this an embedding issue, since IE has it and Gecko doesn't? Also, wouldn't
this cause some pages to layout differently? We expect Gecko to seamlessly
replace IE for Important Embedding Customers; might this not be an area of
cognitive friction for their users?  Is it easy to fix? 

Comment 18

[Daniel Quinlan]

I was planning on filing a separate bug, but it probably would have been
marked as a duplicate of this one, even though this one misses the point.

The problem is very specifically that the width of a textarea changes when the
scrollbar is added after typing some number of lines.  It is very annoying when
you are writing a message for a online forum and did *not* happen with Netscape
4.7.

Another way to fix the problem would be to add the scrollbar to the left of
the textarea and leave the textarea at the original width which is specified
in the HTML for the form anyway.  The scrollbar changes the width, deviating
from the textarea geometry that was requested in the HTML.

Whether or not the scrollbar is always there is an orthogonal issue to the width
changing.  You can fix it by always including the scrollbar (and getting the
width correct!) or you can fix it by adding the scrollbar to the right of the
text area without changing the size of the textarea (this may require relaying
out the page, but that happens if you resize the window anyway).

Comment 19

[TucsonTester3]

Attachment: Minimized test case

Comment 20

[Brad Garcia]

> The problem is very specifically that the width of a textarea changes when the
> scrollbar is added after typing some number of lines.

This cannot be stressed enough.  Go look at bug 72101.  In particular, it has
a testcase where a text box and a text area, both set to the same width.

However, when you look at them, the textarea appears wider.  When you finally
type enough lines to make the scrollbar appear, then you see that the scrollbar
gets displayed inside the textarea box, making the usable columns the same size
as the text box above it.

This can be fixed in one of two ways, and I have no preference between the two.

1. Have the scrollbar always appear.
2. Have the outline of the textarea box stop at the correct column, and have
   the scrollbar appear to the _right_ of the textarea box outline when the
   scrollbar is actually needed.

It makes no sense to define a textarea of width "40" and then make it appear
initially with "41" or "42" columns.

Comment 21

[Martijn Wargers (dead)]

Since bug 72747 and bug 76197 are fixed, I think it is possible/acceptable to do
this with a single css rule inside the textarea selector in forms.css:
overflow-y:scroll.

Comment 22

[Biju]

I have seen many bad user experiences with too many scrollbars on page in IE.
Many intranet application are created by developers who have higher resolutions.
When user have lower resolution they end up seeing lot of scrollbars 
and it is confusing.

Now the resizer control is there at right-bottom corner of TEXTAREA 
so TEXTAREA is easily distinguishable now.

Related bug 72540 is WONTFIX now, I vote this should also be WONTFIX
If web developer always want a scrollbar in TEXTAREA, 
they can add that to their style sheet.

Comment 23

[Charly Molter :lahabana]

I was going through bugs and seen that one. I think like Biju and I even think that this is not a bug anymore. 
UX nowadays seem to remove has much as possible scrollbars therefore I think it should be the same it Textarea.
Moreover Chrome does the same...

Consequently I think this bug should be INVALID or WONTFIX no?

Comment 24

[Mounir Lamouri (:mounir)]

I tend to agree with the last two comments. This is also the behaviour of Chrome and Opera.
I'm marking this WONTFIX.

Please, reopen if you disagree with the rationales given above.

Comment 25

[Martijn Wargers (dead)]

Yeah, disagree with the rationales given above.

However, because every textarea now a resizer widget, they don't look that much as random white rectangles anymore.

However, there is still the problem of suddenly rewrapping when the typed text in the textarea gets too large.

Comment 26

[Charly Molter :lahabana]

So which one of these seem the best solution:
1. Have the scrollbar always appear.
2. Have the outline of the textarea box stop at the correct column, and have
   the scrollbar appear to the _right_ of the textarea box outline when the
   scrollbar is actually needed.

I really don't see the point of having the scrollbar to always appear...