Closed
Bug 162083
Opened 23 years ago
Closed 22 years ago
control-delete deletes to end-of-line instead of end-of-word
Categories
(Core :: DOM: Editor, defect)
Core
DOM: Editor
Tracking
()
RESOLVED
FIXED
mozilla1.3alpha
People
(Reporter: dkindred+mozilla, Assigned: akkzilla)
Details
Attachments
(1 file)
651 bytes,
patch
|
Brade
:
review+
bzbarsky
:
superreview+
|
Details | Diff | Splinter Review |
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020607
BuildID: 2002060700
In, for example, textareas, pressing ctrl-delete deletes from the cursor to end
of line. I assume it should instead delete to the end of the next word (as
Windows does, and to be consistent with control-left, control-right, and
control-backspace).
Reproducible: Always
Steps to Reproduce:
1. Go to "additional comments" textarea for this bug
2. Type
abc def ghi
jkl mno pqr
3. Put cursor before "d"
4. Press ctrl-delete
Actual Results: "def ghi" is erased
Expected Results: should have erased just "def"
Comment 1•23 years ago
|
||
see that too (Linux, 2002080804)
Comment 2•22 years ago
|
||
Akkana--I'm going to reassign this bug to you but I can take it if you prefer.
This bug affects text widgets as well as Composer (presumably).
note: I changed to all platforms but I don't think the Macintosh clients have
this keybinding so it probably doesn't apply there.
Assignee: kin → akkana
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
Assignee | ||
Updated•22 years ago
|
Target Milestone: --- → mozilla1.3alpha
Assignee | ||
Comment 3•22 years ago
|
||
The problem actually wasn't the key binding, it was that we're using the
nsCopyOrDeleteCommand on linux, and that command was deleting to end of line.
This patch makes it delete word.
There's a problem, though: it turns out that the editor doesn't delete word
very well. If you do it repeatedly, we delete up to the space, delete the
space, delete up to the next space, delete the space, etc. That isn't an issue
with the key binding, but a problem with selection making assumptions about
word selections being windows style.
I've filed bug 181926 on the selection problem. I could check this one in
independant of that, unless people think that that bug should block this one.
Assignee | ||
Updated•22 years ago
|
Attachment #107407 -
Flags: superreview?(brade)
Attachment #107407 -
Flags: review?(cmanske)
Comment 4•22 years ago
|
||
Comment on attachment 107407 [details] [diff] [review]
trivial fix
r=brade (only Unix keybindings call this command/code)
Attachment #107407 -
Flags: review?(cmanske) → review+
Assignee | ||
Updated•22 years ago
|
Attachment #107407 -
Flags: superreview?(brade) → superreview?(bzbarsky)
Updated•22 years ago
|
Attachment #107407 -
Flags: superreview?(bzbarsky) → superreview+
Assignee | ||
Comment 5•22 years ago
|
||
Fixed.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•