Open Bug 82160 Opened 23 years ago Updated 2 years ago

TEXTAREAs should always have a vertical scrollbar by default

Categories

(Core :: Layout: Form Controls, defect)

defect

Tracking

()

REOPENED
Future

People

(Reporter: mpt, Unassigned)

Details

(Keywords: testcase)

Attachments

(1 file)

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.
All/All. I can't believe we haven't filed this before.
OS: Mac System 8.5 → All
Hardware: Macintosh → All
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?
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.
mpt, should it be both a vertical, disabled and a horizontal, disabled scrollbar?
4.x has both. IE has just the vertical one. I think just the vertical one is necessary to stop the wrapping problem.
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?
Summary: TEXTAREAs should always have a scrollbar → TEXTAREAs should always have a vertical scrollbar
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.
I think this is a dup
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Summary: TEXTAREAs should always have a vertical scrollbar → [DUP]TEXTAREAs should always have a vertical scrollbar
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.
Summary: [DUP]TEXTAREAs should always have a vertical scrollbar → TEXTAREAs should always have a vertical scrollbar
And what about bug #72101 ? Seems like dup.
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.
> 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.
Bug 64807 is about why our current behavior is different on Linux.
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.
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.
Resummarizing to make puddy happy. Yes, this should be overridable using CSS.
Summary: TEXTAREAs should always have a vertical scrollbar → TEXTAREAs should always have a vertical scrollbar by default
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?
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).
Attached file Minimized test case (deleted) —
> 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.
Keywords: testcase
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.
Assignee: rods → nobody
Status: ASSIGNED → NEW
QA Contact: vladimire → layout.form-controls
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.
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?
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.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
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.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
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...
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: