Closed Bug 85909 Opened 19 years ago Closed 19 years ago
Cannot scroll content of textarea with style attribute "overflow:hidden"
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.1+) Gecko/20010613 BuildID: 2001061304 Textareas with overflow:hidden (presumably to prevent scroll bars from appearing) are unusable when there is too much content to display, as there is no way to scroll the content. It should be possible to use the arrow keys to scroll (by the action of scrolling the content to keep the caret in the visible area), and also to scroll as a side effect of drag-select with the mouse. In short - to have the same behaviour as ordinary textareas. Reproducible: Always Steps to Reproduce: 1.Go to http://www.lycos.co.uk/service/sms/agb.html 2.Click on the "Accept" button 3.Wait for the 34K of horribly broken mess of "HTML" (http://www.lycos.co.uk/service/sms/eingabe.html) to load 4.Type a long message into the textarea (the simulated phone display) Actual Results: The message eventually continues out of sight, and the textarea doesn't scroll to show what you're typing. You cannot scroll this text by any means. You can't select it all either - the behaviour unexpectedly springs the selection end to the top line once the mouse moves below the bottom line. Expected Results: The message continues, and the text scrolls up to keep the caret (and the text you're typing) visible. You can scroll the text up and down by moving the caret with the arrow keys. You can also drag select any text you wish as the text autoscrolls if you move the pointer beyond the top or bottom of the textarea. Using this HTML fragment should demonstrate the problem nicely if you can't get to the above URL: <textarea cols=15 rows=4 name="msg" style="overflow:hidden"></textarea> [Note also that the mis-nesting of tags in Lycos's HTML seems to trigger an inability to render the caret in the textarea. I've tried writing a simplified testcase for this, but fixing the broken HTML makes the bug go away - anyone else care to have a stab?]
Confirmed on Mac OS 9 Mozilla 0.9.1 - also of note is that the cursor moves outside of the confines of the textarea. Just look at the above happy testcase. As discussed in bug 69355 , the World Wide Web Consortium reccomends that the user can't acess stuff outside the confines of an overflow:hidden box. So although the reporter is reporting accurately, this is apparently what mozilla is supposed to do. However, no need to mark this bug is invalid or duplicate - it can be given new life with a new purpose - to prevent the cursor from being displayed if it is moved outside of the box. One more thing - why is the component of this bug "editor"?
No, ignore all that, too. The cursor problem is already known ( Bug 59018 ). Just invalidate this bug.
The component is editor because textareas just use the editor architecture. Marking duplicate of bug 69355. Oh, and please let's not mutate bugs. If a related issue comes up during investigation, just file a separate bug. *** This bug has been marked as a duplicate of 69355 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.