631169 - Unable to scroll using keyboard in large text boxes in new Facebook Messages

Status: RESOLVED WORKSFORME

(Core :: Layout: Form Controls, defect)

Description

[Vivien M. (he/him)]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b11pre) Gecko/20110202 Firefox/4.0b11pre
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b11pre) Gecko/20110202 Firefox/4.0b11pre

The new Facebook Messages uses a single, large text box to enter text. This box starts off at one line, but dynamically grows to 21 lines. If you enter more than 21lines, then no scroll bars appear (which is clearly what Facebook intends - other browsers do the same), but the box happily accepts more than 21 lines of text.

If you do this in IE or Google Chrome, then you can use the up/down arrow keys to move up/down within the text box and change which 21 lines are being displayed. The current nightly build does not let you do that.

This makes it far more difficult to enter/edit messages of over 21 lines with Firefox.

Reproducible: Always

Steps to Reproduce:
1. Enter more than 21 lines of text in the text box in the new Facebook Messages system. The box should display the last 21 lines of text.
2. Using either the mouse or the keyboard, place the insertion point on the top-most line visible in the box. 
2. Press the up arrow key.
Actual Results:  
Nothing. The insertion point moves up (and is now off the screen), but the line where it is are not displayed on screen. 



Expected Results:  
The text in the text box should scroll up one line, following the insertion point.

The same problem occurs with the down arrow and the bottom of the text box. If you type text, it is correctly entered where the insertion point is, off-screen.

Using page up/page down to scroll within that text box sometimes works, but fairly erratically. 

I've tested this in IE8 and Google Chrome, both behave correctly. I have not tested Firefox 3.6. I have also not tested any other sites with large text boxes other than the Facebook Messages system. If no developers have access to the new Facebook Messages system to confirm this, I can try and create sample web page that reproduces the problem.

I can also attempt to make a screenshot series demonstrating the problem if that would be helpful, as I realize that it is fairly difficult to explain in words.

Comment 1

[Vivien M. (he/him)]

I just tested Firefox 3.6.13. The problem is also present there.

Comment 2

[Teodosia Pop]

Works for me using Mozilla/5.0 (Windows NT 6.1; rv:2.0b11) Gecko/20100101 Firefox/4.0b11.

Comment 3

[Vivien M. (he/him)]

I tested 4.0b11 too; I still see the problem.

Are you using the new (invitation-only for now?) Facebook messages without the scrollbars and that doesn't let you enter a subject for your message? Would it be helpful if I provided a screenshot?

Comment 4

[Teodosia Pop]

(In reply to comment #3)
> Would it be helpful if I provided a screenshot?

Yes, it would.

Comment 5

[Vivien M. (he/him)]

Attachment: Screenshot showing insertion point

Comment 6

[Vivien M. (he/him)]

Attachment: Screenshot after hitting down arrow about 6 times

Comment 7

[Vivien M. (he/him)]

I'll try to explain what these two screenshots (both of 4.0b11) show.

In the first one, notice that the insertion point is about 4 lines from the bottom of the test box, between the 'd' and 'o' in the line that begins "neque dolor".

In the second one, I pressed the down arrow key about 5-6 times. The insertion point moved down 5-6 lines, but is now off-screen. The text did not scroll - you'll note that the "Lorem ipsum dolor sit amet." is the top line in both screenshots. 

If it would be helpful, I can make screenshots in Chrome, IE8, or Opera (I've tested the latest versions of all three, they all behave the way I would expect) that will show the text scrolling and the insertion point remaining visible on screen. (I also tested this with Firefox 3.6.13, it's just as broken as in 4, and I tested 3.6.13 with a spoofed IE8 UI, same behaviour. So probably not an evangelism issue...)

Comment 8

[(no longer active)]

Confirmed on trunk.  The same problem is also present in 3.6 and 3.5 too.

The problem is that we don't scroll the selection into view for textareas with overflow:hidden.  You can reproduce using the testcase in the URL field.

This is not a regression, but it's a bug in Gecko which is not present in Webkit and Opera, and is something which is now visible in a high-profile website.  Should we get this fixed in 2.0?

Comment 9

[(no longer active)]

Another test case:

data:text/html,<div style="overflow:scroll; height: 50px;"><textarea style="overflow: hidden"></textarea><br><br><br></div>

If you press Enter multiple times in the textarea in this test case, you'll see that we scroll the div instead of the textarea.  This behavior is also visible on facebook.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Imo, we shouldn't allow scrolling here if overflow:hidden is set.  That's how all other overflow:hidden things work.  If facebook is depending on scrolling being allowed in that case, that sounds like a facebook bug...

In any case, we should NOT be touching this for 2.0.  Again, imo.

Comment 11

[(no longer active)]

(In reply to comment #10)
> Imo, we shouldn't allow scrolling here if overflow:hidden is set.  That's how
> all other overflow:hidden things work.  If facebook is depending on scrolling
> being allowed in that case, that sounds like a facebook bug...

Not allowing scrolling is one thing, not allowing keyboard navigation is another.  This causes the user to not be able to see what they type if the length of the message extends beyond the height of the textarea.

Given the fact that we don't expose the scroll position of the inner anonymous div to web content, I don't see why we should not make an exception for text controls (as far as keyboard navigation is concerned.)

Comment 12

[(no longer active)]

And also, scrolling parent elements in response to keyboard navigation commands (as I indicated in comment 9) is pretty broken...

Comment 13

[Boris Zbarsky [:bzbarsky]]

How is that situation different from an overflow:hidden contenteditable div?

Comment 14

[(no longer active)]

(In reply to comment #13)
> How is that situation different from an overflow:hidden contenteditable div?

They're similarly broken...  Except that in the textarea case, Ctrl+Home/End actually dos scroll the textarea, but in the case of contenteditable divs, it doesn't.

Comment 15

[Boris Zbarsky [:bzbarsky]]

> They're similarly broken...

And in other UAs?

Comment 16

[(no longer active)]

(In reply to comment #15)
> > They're similarly broken...
> 
> And in other UAs?

Chrome and Opera work fine with a testcase like:

data:text/html,<div contenteditable style="overflow:hidden;height: 100px">foo</div>

Comment 17

[Boris Zbarsky [:bzbarsky]]

If it's not contenteditable, do they also allow scrolling it with the keyboard arrows?

Comment 18

[(no longer active)]

(In reply to comment #17)
> If it's not contenteditable, do they also allow scrolling it with the keyboard
> arrows?

Hmm, how would you scroll a non-contenteditable div?  By focusing you mean?

If you're thinking about a testcase such as this, then no, they don't allow scrolling (and IMO, rightly so):

data:text/html,<div tabindex=1 style="overflow:hidden;height: 100px">foo<br>bar<br>baz<br>foo<br>bar<br>baz<br></div>

Let me reiterate.  This bug is *only* about keyboard navigation within editable fields.  For all other intents and purposes, we should treat overflow:hidden as we do now.

Comment 19

[Mike Beltzner [:beltzner, not reading bugmail]]

Maybe a .x, but not a blocker.

Comment 20

[Boris Zbarsky [:bzbarsky]]

> then no, they don't allow scrolling 

OK.

I suppose I can see some sort of hackery for editable stuff that makes it behave differently from other overflow:hidden stuff.  But that still seems broken to me....

Comment 21

[(no longer active)]

(In reply to comment #20)
> > then no, they don't allow scrolling 
> I suppose I can see some sort of hackery for editable stuff that makes it
> behave differently from other overflow:hidden stuff.  But that still seems
> broken to me....

So, do you think that we should ideally preserve the current behavior?

Comment 22

[Boris Zbarsky [:bzbarsky]]

I think there's a benefit to making overflow:hidden behave consistently whether it's editable or not, yes....

Comment 23

[(no longer active)]

(In reply to comment #22)
> I think there's a benefit to making overflow:hidden behave consistently whether
> it's editable or not, yes....

FWIW, I really don't think that's the right thing to do at all.  CSS defines overflow:hidden so that the UA should not present any scrolling UI.  What we do now, however, is not really disabling scrolling UI, and it will prevent users from actually seeing what they're editing without a workaround for most cases.

With my user hat on, this bug makes it impossible to type long messages (or messages spaning a lot of lines) in Facebook, but all that the facebook authors have asked the browser to do is to hide scrollbars for the textbox.

Comment 24

[Boris Zbarsky [:bzbarsky]]

We used to do the "just hide scrollbars" thing.  Turned out most people setting overflow:hidden actually mean "do not let the user see this, ever", iirc, which is why we changed behavior.  At least as I recall; dbaron would know better.

I understand that it sucks in this case, but the fact is that the page _asked_ for a textbox with no way to scroll it.  Quite explicitly.

I guess we could auto-scroll the insertion point into view in editable contexts to work around people who do silly stuff like that and then only test in Webkit.  But it's just sad that we have to add more special-cases to handle them.  :(

Comment 25

[Vivien M. (he/him)]

(In reply to comment #24)
> I guess we could auto-scroll the insertion point into view in editable contexts
> to work around people who do silly stuff like that and then only test in
> Webkit.  But it's just sad that we have to add more special-cases to handle
> them.  :(

It's not just WebKit. I tested Opera (latest release) and IE8, too, along with Chrome. Same behaviour with the scrolling in all of them; I seem to remember there were other weird things with the Facebook Messages pages in Chrome.

Sometimes I wonder if the Facebook folks intended for these boxes to be limited to 21 lines in the Messages feature; elsewhere on their site, they use the same kind of boxes, but let them grow infinitely, which avoids this problem.

Comment 26

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I think I could stomach letting users scroll editable overflow:hidden content. If it's supposed to be editable, the user should be able to edit even the content that isn't visible.

Comment 27

[(no longer active)]

Comment 24 makes me hesitate, but still the gain here outweighs the suckiness IMO... :/

Comment 28

[Alin Ilea, Desktop Test Engineering]

Marking this as Resolved > wfm since I cannot reproduce the issue using the latest Fx versions, the last activity on this issue was 11 years ago and it might not be relevant anymore. Feel free to re-open if the issue is still reproducible on your end in the latest FF versions.