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

VERIFIED FIXED in mozilla1.0

Status

()

Core
Layout: Form Controls
P3
critical
VERIFIED FIXED
18 years ago
16 years ago

People

(Reporter: Stephen Moehle, Assigned: kinmoz)

Tracking

(Blocks: 1 bug, {topembed+})

Trunk
mozilla1.0
topembed+
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [caret][behavior])

Attachments

(3 attachments)

(Reporter)

Description

18 years ago
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.
(Reporter)

Comment 1

18 years ago
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

18 years ago
reassigning
Assignee: rods → beppe

Comment 3

18 years ago
reassigning to anthony
Assignee: beppe → anthonyd
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
Target Milestone: --- → mozilla0.9.1

Comment 4

18 years ago
QA Contact Update
QA Contact: bsharma → vladimire

Comment 5

17 years ago
Isn't this a keybindings issue?

Comment 6

17 years ago
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.
(Reporter)

Comment 7

17 years ago
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.
(Reporter)

Comment 8

17 years ago
Created attachment 30665 [details]
HTML page with table to illustrate my previous comment.

Comment 9

17 years ago
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).
(Assignee)

Comment 10

17 years ago
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

17 years ago
reassign to kin for further triage (and possible reassignment)
Assignee: anthonyd → kin
(Assignee)

Comment 12

17 years ago
*** Bug 65465 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

17 years ago
Target Milestone: mozilla0.9.1 → mozilla0.9.2

Updated

17 years ago
Keywords: correctness
Whiteboard: [caret][behavior]

Updated

17 years ago
Target Milestone: mozilla0.9.2 → mozilla1.0

Updated

17 years ago
OS: Windows NT → All
Hardware: PC → All

Comment 13

17 years ago
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.
(Assignee)

Comment 14

17 years ago
Bulk move of mozilla1.0 bugs to mozilla.1.0.1. I will try to pull some of these
back in if I can.
Target Milestone: mozilla1.0 → mozilla1.0.1
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.
Severity: normal → critical
Keywords: mozilla1.0, nsbeta1, topembed

Comment 16

16 years ago
topembed+
Keywords: topembed → topembed+
(Assignee)

Updated

16 years ago
Status: NEW → ASSIGNED
Target Milestone: mozilla1.0.1 → mozilla1.0
(Assignee)

Comment 17

16 years ago
Created attachment 78794 [details]
Test Case (Allows testing of scroll-into-view code in all directions)
(Assignee)

Updated

16 years ago
Blocks: 108120
(Assignee)

Comment 18

16 years ago
Created attachment 78958 [details] [diff] [review]
Patch Rev 1
(Assignee)

Updated

16 years ago
Whiteboard: [caret][behavior] → [caret][behavior] FIX IN HAND, need r=, sr=, a=

Comment 19

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

sr=sfraser
Attachment #78958 - Flags: superreview+
(Assignee)

Updated

16 years ago
Whiteboard: [caret][behavior] FIX IN HAND, need r=, sr=, a= → [caret][behavior] FIX IN HAND, need r=, a=

Comment 20

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

r=brade
Attachment #78958 - Flags: review+
(Assignee)

Updated

16 years ago
Keywords: adt1.0.0
Whiteboard: [caret][behavior] FIX IN HAND, need r=, a= → [caret][behavior] FIX IN HAND, need a=

Comment 21

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

a=asa (on behalf of drivers) for checkin to the 1.0 branch
Attachment #78958 - Flags: approval+

Comment 22

16 years ago
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.
(Assignee)

Comment 23

16 years ago
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?
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
Whiteboard: [caret][behavior] FIX IN HAND, need a= → [caret][behavior][FIXED_ON_TRUNK] need adt approval for mozilla1.0.0 checkin

Comment 24

16 years ago
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

16 years ago
Verifying on OSX build 2002-04-17-03-trunk, and Linux 2002-04-17-07-trunk
Whiteboard: [caret][behavior][FIXED_ON_TRUNK] need adt approval for mozilla1.0.0 checkin → [caret][behavior][VERIFIED_ON_TRUNK] need adt approval for mozilla1.0.0 checkin

Comment 26

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

Status: RESOLVED → VERIFIED
Whiteboard: [caret][behavior][VERIFIED_ON_TRUNK] need adt approval for mozilla1.0.0 checkin → [caret][behavior] need adt approval for mozilla1.0.0 checkin
(Assignee)

Updated

16 years ago
Whiteboard: [caret][behavior] need adt approval for mozilla1.0.0 checkin → [caret][behavior][FIXED_ON_TRUNK] need adt approval for mozilla1.0.0 checkin

Comment 27

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

Comment 28

16 years ago
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.
Keywords: adt1.0.0 → adt1.0.0+
(Assignee)

Comment 29

16 years ago
Fixed on MOZILLA_1_0_0_BRANCH:

    mozilla/content/base/src/nsSelection.cpp  revision 3.119.2.4
Keywords: fixed1.0.0
Whiteboard: [caret][behavior][FIXED_ON_TRUNK] need adt approval for mozilla1.0.0 checkin → [caret][behavior]

Comment 30

16 years ago
Verifying on 07/17 branch on windows98 and linux RedHat
Keywords: fixed1.0.0 → verified1.0.0
You need to log in before you can comment on or make changes to this bug.