Closed Bug 385565 Opened 17 years ago Closed 17 years ago

Alt+Left and Alt+Backspace (Ctrl+Arrow/Ctrl+Backspace on Windows) stop at the wrong places relative to punctuation in textboxes

Categories

(Core :: DOM: Editor, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED

People

(Reporter: jruderman, Assigned: roc)

References

()

Details

(Keywords: regression, testcase)

Steps to reproduce:
1. Put http://en.wikipedia.org/wiki/Zapfino in the address bar and put the caret at the right.
2. Alt+Backspace twice.

Actual:
http://en.wikipedia.org/wiki/Zapfino
http://en.wikipedia.org/wiki
http://en.wikipedia.org

Expected:
http://en.wikipedia.org/wiki/Zapfino
http://en.wikipedia.org/wiki/
http://en.wikipedia.org/

I noticed this because I usually get to a wikipedia article by typing "en", down, alt+backspace, <article name>.  This change made it so my URLs no longer have "/" after "wiki".  I imagine it breaks subtle habits that other people have as well, and it might break Mac OS X convention.
Flags: blocking1.9?
Similarly on Windows, using shift+ctrl+left arrow selects past the separator.  This is definitely a textframe regression, this works in 2007-06-19-04, and fails in 2007-06-21-07.
OS: Mac OS X → All
Hardware: PC → All
Assignee: nobody → roc
Summary: Alt+Left and Alt+Backspace stop at the wrong places relative to punctuation in URLs → Alt+Left and Alt+Backspace (Ctrl+Arrow/Ctrl+Backspace on Windows) stop at the wrong places relative to punctuation in URLs
Flags: blocking1.9? → blocking1.9+
Changing summary since this problem is neither limited to URLs nor to 
the address bar.
Summary: Alt+Left and Alt+Backspace (Ctrl+Arrow/Ctrl+Backspace on Windows) stop at the wrong places relative to punctuation in URLs → Alt+Left and Alt+Backspace (Ctrl+Arrow/Ctrl+Backspace on Windows) stop at the wrong places relative to punctuation in textboxes
WFM Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a8pre) Gecko/2007090104 Minefield/3.0a8pre

Fixed by bug 389421, I'm guessing.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Depends on: 389421
VERIFIED in
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007090105 Minefield/3.0a8pre
Status: RESOLVED → VERIFIED
Flags: in-testsuite?
I know this bug claims to be verified/fixed, but I'm still having a LOT 
of problems with ctrl+arrow stopping at the wrong places in SeaMonkey trunk 
Gecko/2007100703 (that's 2007-10-07, which is over a month later than the 
date on which this bug was marked fixed).

I'll try to come up with some reproducible test cases.  Shouldn't take long.

Shall I file another bug about this?  Or reopen this one?
Below is a snippet of text with which I have the problem.  Copy and paste
it into the bugzilla comment editor box, and try it for yourself.

The problem is seen with any word that is preceeded by a punctuation 
character, such as a period or an open (left) parenthesis.  

- ------------------ begin snippet ----------------
Mailnews silently ignores the failure, but does go on to update the .msf 
file (or perhaps the .msf file was updated first, before the failure to open 
the .rc file).  The .msf file contains a (normally redundant) copy
of the information found in the .rc file.  When mailnews restarts, it reads
- ------------------ end snippet ----------------

ctrl-left arrow should stop at the beginning of the current word or the preceeding word.
ctrl-right arrow should stop at the end of the current word, or the next one.

But when a word is preceeded by a punctuation character (such as in 
"(normally" or ".msf" or ".rc"), ctrl-right arrow stops after the character, 
not before it, and ctrl-left arrow skips over the word, over the punctuation
and over the space that preceeds the word, and stops at the tail end (right
side) of the preceeding word.  

This is the problem I reported in bug 392809, which was marked as a duplicate
of this bug.  But that problem is as unfixed today as the day I filed it.
Nelson, I reopened your bug for you.
> This is the problem I reported in bug 392809

The specific testcase you reported in bug 392809 was fixed by the fix for this bug, as far as I can tell. It certainly works for me on trunk. So I think marking it as a duplicate was fair.

The new testcase you have there now is not fixed, and I'll fix it in bug 392809.
This seems to have regressed again. I've filed bug 407155.
You need to log in before you can comment on or make changes to this bug.