376 bytes, text/html
1.21 KB, text/html
2.44 KB, patch
|Details | Diff | Splinter Review|
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.
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.
Assignee: rods → beppe
reassigning to anthony
Assignee: beppe → anthonyd
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
Target Milestone: --- → mozilla0.9.1
QA Contact Update
QA Contact: bsharma → vladimire
Isn't this a keybindings issue?
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.
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.
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).
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.
reassign to kin for further triage (and possible reassignment)
Assignee: anthonyd → kin
*** Bug 65465 has been marked as a duplicate of this bug. ***
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.
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
Keywords: topembed → topembed+
Status: NEW → ASSIGNED
Target Milestone: mozilla1.0.1 → mozilla1.0
Created attachment 78794 [details] Test Case (Allows testing of scroll-into-view code in all directions)
Whiteboard: [caret][behavior] → [caret][behavior] FIX IN HAND, need r=, sr=, a=
Comment on attachment 78958 [details] [diff] [review] Patch Rev 1 sr=sfraser
Attachment #78958 - Flags: superreview+
Whiteboard: [caret][behavior] FIX IN HAND, need r=, sr=, a= → [caret][behavior] FIX IN HAND, need r=, a=
Comment on attachment 78958 [details] [diff] [review] Patch Rev 1 r=brade
Attachment #78958 - Flags: review+
Whiteboard: [caret][behavior] FIX IN HAND, need r=, a= → [caret][behavior] FIX IN HAND, need a=
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+
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.
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: 17 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
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!
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
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
Whiteboard: [caret][behavior] need adt approval for mozilla1.0.0 checkin → [caret][behavior][FIXED_ON_TRUNK] need adt approval for mozilla1.0.0 checkin
verified fixed on win 2k trunk build 2002041606, linux trunk build 2002041707 and Mac OS X trunk build 2002041703
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+
Fixed on MOZILLA_1_0_0_BRANCH: mozilla/content/base/src/nsSelection.cpp revision 184.108.40.206
Whiteboard: [caret][behavior][FIXED_ON_TRUNK] need adt approval for mozilla1.0.0 checkin → [caret][behavior]
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.