68331 - Moving caret in TEXTAREA to start of line can cause page to scroll horizontally

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect, P3)

Description

[Stephen Moehle]

Assume you have an html page with a TEXTAREA on it and that the page is scrolled
to the right but that the TEXTAREA is fully visible.  If you use the arrow keys
to move to the beginning of a line by either arrowing left or by arrowing up or
down onto a line with text, the browser window will scroll all the way to the left.

To reproduce:
1) Viewing this bug, make your browser window narrow enough so that you get a
horizontal scroll bar.
2) Scroll the browser window so that it is scrolled to the right but try to make
the Description TEXTAREA fully visible.
3) In the Description TEXTAREA, type a letter.  Any letter will do.
4) Arrow left once.  The browser window will now have scrolled all the way to
the left.

I would expect that navigating around in a TEXTAREA that is fully visible would
have no effect on the horizontal scroll position of the browser window.

This bug may be related to bug 65465.

Tested with Mozilla 2001020904 on NT4.

Comment 1

[Stephen Moehle]

My steps to reproduce are a little off since existing bugs do not have
Description fields.  You can try with the Additional Comments field, but that is
a little tricky since it is so close to the left edge.  I would suggest trying
my scenario with the Keywords TEXTAREA as it behaves the same way.

Comment 2

[rods (gone)]

reassigning

Comment 3

[rubydoo123]

reassigning to anthony

Comment 4

[Vladimir Ermakov]

QA Contact Update

Comment 5

[Simon Fraser [no longer active]]

Isn't this a keybindings issue?

Comment 6

[Akkana Peck]

What I'm seeing on linux (submitter, please correct if you see something different):

As long as I'm not at the beginning of a line in the text field, pressing
left-arrow moves the caret and does not scroll the page.  Once I get to the
beginning of a line, then left-arrow now scrolls the page instead of wrapping
around to the beginning of the previous line, as I would expect, or doing
nothing, which would also be reasonable behavior.

I'll speculate that once the caret makes it to beginning of line, the selection
controller is answering that it doesn't handle the move left command, so the key
binding system correctly bubbles the event up to the next possible handler, the
window, which scrolls.

If so, the selection controller should be fixed so that it always handles the
left/right arrow keys, even if it's at the beginning of  a line (and perhaps it
should wrap around between the end of line N and the beginning of line N+1; at
least, that's what 4.x did on Unix, how about the other platforms?)  

We already seem to do the right thing for up/down -- at least, when I'm at the
last line of a textarea and I hit downarrow, the containing page does not scroll.

Comment 7

[Stephen Moehle]

What you are seeing is different from I see. In particular, I see the page
scrolling with the up and down arrow keys. I have attached a very simple html
page with a two cell table to help me illustrate what I am seeing. The first
cell is just text. The second cell is a 5x80 TEXTAREA.

Both cases assume the browser window is narrow enough that the horizontal scroll
bar is present but wide enough so that the TEXTAREA can fit entirely within the
browser window.

Case 1: Up and down arrow keys cause page to scroll.
1) Scroll the page so that the TEXTAREA is entirely visible.
2) Place the cursor at the beginning of the first line of the TEXTAREA using the
mouse.
3) Press the down arrow key.
4) Browser window scrolls horizontally.

Case 2: Left arrow scrolls page as soon as cursor reaches the beginning of the
line. Akkana's description sounds like the page scrolls on the left arrow key
_after_ the cursor has reached the beginning of the line.
1) Scroll the page so that the TEXTAREA is entirely visible.
2) Place the cursor at the second position of the second line (between the 'S'
and the 'e') of the TEXTAREA using the mouse.
3) Press the left arrow key to move cursor to the beginning of the line.
4) Browser window scrolls horizontally which should not have happened.
5) Scroll the page so that the TEXTAREA is completely visible again.
6) Cursor is still at the beginning of the second line. Press the left arrow.
7) Cursor moves to the end of the first line, but the browser window does not
scroll. This is what I would expect but seems to be the opposite of what Akkana
is seeing.

Comment 8

[Stephen Moehle]

Attachment: HTML page with table to illustrate my previous comment.

Comment 9

[Akkana Peck]

Yes, I see the same thing you see in both Case 1 and Case 2.  An important point
to note is that the caret does move in both cases, i.e. the selection controller
is doing its thing.  Some possibilities:
- the event is bubbling up (someone, maybe the selection controller, forgot to
call preventBubble/preventDefault)
- the window controller or some aspect of xul or xbl key bindings is forgetting
to check whether default is prevented.
- a rogue xul keybinding is firing even though the event has already been
consumed by xbl
- the text control frame is too aggressive about causing the parent window to
scroll.

Adding Kin in case he knows any scrolling-related secrets (he at least knows
something about the last case I mentioned).

Comment 10

[kinmoz]

This is probably my bug, i think I have a bug like this on my plate already.

There is a bug in my auto scrolling code that is causing the parent view to 
scroll even when it shouldn't. Note, that my code intentionally propogates 
scroll requests up the view chain so that we always see the caret when typing 
and arrowing around.

We can verify that it is indeed my bug by modifying the call to 
ScrollRectIntoView() in nsTypedSelection::ScrollIntoView() so that a PR_FALSE is 
passed in for the scrollParentViews arg.

Comment 11

[Kathleen :Brade]

reassign to kin for further triage (and possible reassignment)

Comment 12

[kinmoz]

*** Bug 65465 has been marked as a duplicate of this bug. ***

Comment 13

[Niels Aufbau]

I ran into a similar where the page scrolls to the right:

1. Go to http://www.mozilla.org/quality/help/bugzilla-helper.html.
2. Make the page just big enough to display the entire "URL" field at the same
time the page is scrolled all the way left.  (This makes the window about 750
pixels wide.)
3. Fill the field in with some long text.
4. Scroll the text field all the way to the left.
5. Scroll the page all the way to the left.  (Because of step 2, the entire text
field should still be visible, but just barely.)
6. Click at the beginning of the text field and hit the right arrow key a bunch
of times.

When the caret first reaches a point that makes the text field scroll, the page
scrolls to the right a little bit.  When it goes past the last character, the
page scrolls to the right again.

I can also get this to happen with a multi-line text field on the same page, but
I have to fill up a line with non-space characters (preventing wrapping).  If I
do that, pressing the end key will scroll the page right, and pressing the home
key will scroll the page left, even though the entire text field can fit within
the window.

Comment 14

[kinmoz]

Bulk move of mozilla1.0 bugs to mozilla.1.0.1. I will try to pull some of these
back in if I can.

Comment 15

[Mike Pinkerton (not reading bugmail)]

this is a serious problem. i can't use bugzilla at all if the window has a
horizontal scrollbar. we have to fix this for beta1 and i'm sure our embedding
clients will be ticked about it too.

Comment 16

[saari (gone)]

topembed+

Comment 17

[kinmoz]

Attachment: Test Case (Allows testing of scroll-into-view code in all directions)

Comment 18

[kinmoz]

Attachment: Patch Rev 1

Comment 19

[Simon Fraser [no longer active]]

Comment on attachment 78958 [details] [diff] [review]
Patch Rev 1

sr=sfraser

Comment 20

[Kathleen :Brade]

Comment on attachment 78958 [details] [diff] [review]
Patch Rev 1

r=brade

Comment 21

[Asa Dotzler [:asa]]

Comment on attachment 78958 [details] [diff] [review]
Patch Rev 1

a=asa (on behalf of drivers) for checkin to the 1.0 branch

Comment 22

[scottputterman]

If you haven't already, please land this on the trunk and when it's gone through
testing, please update this bug with the results.

Comment 23

[kinmoz]

Fixed on TRUNK:

    mozilla/content/base/src/nsSelection.cpp  revision 3.121

Can I get someone to verify this in today's build so that I can request adt 
approval to check it into the MOZILLA_1_0_0_BRANCH?

Comment 24

[gerardok]

terri, please verify this bug is fixed in the trunk.  The adt needs to know it's 
tested before the fix is checked into the branch. thanks!

Comment 25

[Vladimir Ermakov]

Verifying on OSX build 2002-04-17-03-trunk, and Linux 2002-04-17-07-trunk

Comment 26

[Vladimir Ermakov]

Once fixed on the branch, change the adt keyword to fixed1.0.0, and once
verified on the branch, add verified1.0.0 keyword.

Comment 27

[Terri Preston]

verified fixed on win 2k trunk build 2002041606, linux trunk build 2002041707
and Mac OS X trunk build 2002041703

Comment 28

[Jaime Rodriguez, Jr.]

adt1.0.0+ (on ADT's behalf) approval for checkin to the 1.0 branch. Pls check
this into the branch and trunk today. Once, you have landed this on the branch,
pls mark as fixed1.0.0.

Comment 29

[kinmoz]

Fixed on MOZILLA_1_0_0_BRANCH:

    mozilla/content/base/src/nsSelection.cpp  revision 3.119.2.4

Comment 30

[Vladimir Ermakov]

Verifying on 07/17 branch on windows98 and linux RedHat