85909 - Cannot scroll content of textarea with style attribute "overflow:hidden"

Status: VERIFIED DUPLICATE of bug 69355

(Core :: DOM: Editor, defect)

Description

[Francis Chin]

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?]

Comment 1

[Emlyn Shannon]

Attachment: HTML for a test case of this problem

Comment 2

[Emlyn Shannon]

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"?

Comment 3

[Emlyn Shannon]

No, ignore all that, too. The cursor problem is already known ( Bug 59018 ).
Just invalidate this bug.

Comment 4

[Boris Zbarsky [:bzbarsky]]

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 ***

Comment 5

[sujay]

verified.