Closed Bug 92850 Opened 23 years ago Closed 18 years ago

CTRL-RightArrow moves to end of word before end of line.

Categories

(Core :: DOM: Selection, defect, P3)

Product:
Core
Component:
DOM: Selection
Platform:
x86
Windows 2000
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
mozilla1.0.1

People

(Reporter: kinmoz, Unassigned)

Details

This problem was originally reported in bug 88164 by Brent 
(simpleeqbest@hotmail.com):

------- Additional Comments From Brent 2001-07-30 14:17 -------

Editor is much better on build 2001073003 but still at least 2 problems:
Shift right does not always move cursor correctly.
1. Type a line of text with spaces
2. Hit "end"
3. Append a space and some text to the line.
4. Hit "home"
5. Hit shift right arrow repeatedly.

Cursor will move to beginning of each word, which is correct.
But on last word before more text was appended, cursor will move to
original end of line, which is wrong.

Editor still has other probs.  While editing this text,
changing "cursor will move to end of last word on original line"
to "cursor will also move to original end of line" caused
that text to vanish from the display.  Text was still present,
just not displayed.  Had to add and delete some
junk to get the display back.

Tested build 2001073003 Windows version.



------- Additional Comments From Brent 2001-07-30 14:26 -------

Mistake in editor bug report on build 2001073003:
The key that moves to beginning of next word is

ctrl right arrow  not  shift right arrow
marking unverified because 3 people here so far cannot reproduce this.  can you 
give more data?  is this a form text area? a composer? a mail composer?  a url 
would be most helpful. hmm cant mark unverified. iwill hold onto it for a while 
then
reporter, please provide more reproducible steps.
Ok, hope this clarifies.  I can reproduce this bug every time.

In the comment box used to type this report:
1. Type in a line of ordinary text such as this one.
2. Hit the End key.
3. Type in "more text".
4. Hit home to get to start of line.
5. Hit ctrl right arrow many times (12 times if using text of step 1)

After one of the ctrl right arrows, cursor will be positioned at original end of
line (just after the period on "such as this one.more text" if using text of
step 1.)


I can reproduce this.
Priority: -- → P3
Target Milestone: --- → mozilla1.0
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
The problem I see is even worse because it happens all the time.

1. Compsose new mail.
2. Type some text with spaces.
3. Press home. 
4. Press Ctrl+Right arrow. 

Result: Goes to end of word before next word. Take *twice*as long to traverse
text with Ctrl+right arrow. Ctrl+left arrow works fine.

Can we fix this for 1.0? 

Also OS=All as I see this on Linux.
Simplified test for this bug.
0.9.9 for Linux (build 2002031008) has this bug.

Go to a web page with a text area, such as the one used to type this.

In the text area, type:
<Enter>a<Home><End>b<Home><Ctrl-Right Arrow>

Caret will be between 'a' and 'b'.  Caret should be after 'b'.

Bugzilla will not let me change the OS to all.  Says only the owner or submitter
of sufficiently empowered user may do that.  But I _am_ the submitter.
Even simpler test:

Type:
<Enter>a<End>b<Home><Ctrl-RightArrow>

Caret will be between 'a' and 'b'.  Caret should be after 'b'.

--------------
Worse is the slightly different bug Pratik talks about.
A test for that bug:

Type:
a b<Home><Ctrl-RightArrow>

Caret will be between 'a' and ' '.  Caret should be between ' ' and 'b'.
Another <Ctrl-RightArrow> moves the caret to between ' ' and 'b'.
<Ctrl-LeftArrow> works correctly.


Can't get this bug to happen in 1.1b.  Last saw it in 1.1a.
You're right. It does seem fixed. (Build 2002080408, Win2000). But this also
happens on Linux and I'm not sure if its fixed there. Will confirm it when I get
on my linux box (probably on monday).
Its not fixed on linux (Build 2002081204). I don't know if I should file a new
bug for this (considering this bug is marked Win 2k) or leave this open and mark
it for linux. What about other OSes? Anyone on Mac? Solaris?
I filed bug 142120 about the Ctrl RightArrow problem in Linux that Pratik talks
about.

This bug is about Ctrl RightArrow not working correctly after hitting the End
key and then adding more text to a line.
Found a way to get this bug to happen in 1.1b (build 2002072204, Windows):

<Enter>a<Ctrl-End>b<Home><Ctrl-RightArrow>
Simpler, happens even in the URL text entry line (build 2002072204, Windows):

a<Ctrl-End>b<Home><Ctrl-RightArrow>
Another case (build 2002072204, Windows):

b<Ctrl-Home>a<Home><Ctrl-RightArrow>
Another case that doesn't work (build 20020826, Windows):

a<Enter>b<UpArrow>c<Home><Ctrl-RightArrow>
The ways this bug manifests changes a little from build to build.  In 1.3b on
Windows (build 2003021008) this bug happens in the following ways.

At start of textarea:
b<UpArrow>a<UpArrow><Ctrl-RightArrow>

At end of textarea:
a<DownArrow>b<Home><Ctrl-RightArrow>

Anywhere in textarea:
a<Enter><LeftArrow>b<Ctrl-LeftArrow><Ctrl-RightArrow>

a<Enter><Backspace>b<Ctrl-LeftArrow><Ctrl-RightArrow>

In 1.4 RC1 (build 2003052908, Windows) this bug happens opposite to the way it
used to.

In an empty textarea, type:

a<Space><Ctrl-End>b<Home><Ctrl-RightArrow>

Caret stops after the 'b'.  Caret should stop before the 'b'.
Moving to Core/Selection.

I suspect this is WFM, but I can't tell for sure as I'm not on Windows. If anybody CC'ed on this bug is still around, could you please try to reproduce with the various steps described in comments and report whether anything is still broken?
Assignee: mjudge → selection
Component: Editor → Selection
QA Contact: sujay
I haven't seen this bug for a long time now, ever since bug 142120 was fixed.  Just tried it on Firefox 1.5.0.4 in Linux, and could not reproduce any of the broken behavior.  May as well mark it fixed.
WORKSFORME, per comments 19 and 20.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.