delete-line sets caret to beginning of document

VERIFIED FIXED in M18

Status

()

Core
Editor
P2
normal
VERIFIED FIXED
18 years ago
17 years ago

People

(Reporter: Akkana Peck, Assigned: Akkana Peck)

Tracking

({regression})

Trunk
x86
Linux
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [rtm++])

(Assignee)

Description

18 years ago
In composer or html mail compose, type or paste enough text that it wraps and
creates three lines.  Starting somewhere in the middle of the second line, do a
^A (home) followed by ^K (delete to end of line).  The right stuff is deleted,
but the caret then warps back to the beginning of the document.
(Assignee)

Comment 1

18 years ago
This is a recent regression, and makes keyboard navigation very difficult since
you suddenly end up at an unpredictable location -- basically, it makes
delete-to-end useless.
Status: NEW → ASSIGNED
Keywords: regression, rtm

Comment 2

17 years ago
setting to m19 as this is a pretty big user issue for unix people.  unless 
akkana disagrees?

anthonyd
Target Milestone: --- → M19

Comment 3

17 years ago
there isn't dataloss, but yes it is annoying -- which can wait till after rtm
Whiteboard: [rtm-]
Target Milestone: M19 → Future
(Assignee)

Comment 4

17 years ago
Delete line is basic functionality, which every Unix editor supports.  If we
don't offer it (or do something wonky instead, rendering it useless), no one
currently using Unix editors will use our mail product -- they'll stick with 4.x
or whatever other mailer they're using.  Besides, this had been working fine up
'til quite recently.
Whiteboard: [rtm-]
(Assignee)

Updated

17 years ago
Keywords: 4xp
(Assignee)

Updated

17 years ago
Priority: P3 → P2

Comment 5

17 years ago
had a long talk with akkana on this one. This is a regression form previous
releases, this is also a common and expected function in any mail app on unix.
Unix users expect this behavior, there is also the potential for losing the
caret, if the user has scrolled so the top of the page is out of view, at that
point the caret is lost and is not easily discoverable.

waiting for akkana to attach the patch and have it reviewed.
Whiteboard: [rtm+ waiting for patch to be attached]

Comment 6

17 years ago
akkana, what's the patch?  Is this something that I need to look at?  im watching 
the bug report, so let me know if I need to look at this...
(Assignee)

Comment 7

17 years ago
I don't have a fix yet -- I just reported the bug yesterday!
(Assignee)

Comment 8

17 years ago
Delete-to-end just extends the selection then calls the normal delete selection
method.  So this is probably related to the other problems with caret placement
after delete selection when the selection includes a beginning or end of line,
i.e. bug 54452.  Setting dependency, but I'll try looking into it.
Depends on: 54452

Comment 9

17 years ago
Akkana, please include the required information per the rtm checkin rules
Whiteboard: [rtm+ waiting for patch to be attached] → [rtm+ NEED INFO]
(Assignee)

Comment 10

17 years ago
- See beppe's comments re our discussion for the seriousness of this bug.
- I don't know how long it'll take to fix, may have to talk to Joe re how the
selection-resetting works and re bug 54452.
Whiteboard: [rtm+ NEED INFO] → [rtm+
(Assignee)

Comment 11

17 years ago
It looks like the problem here was the action specified, which should have been
eNone rather than eNext.  This patch seems to fix it and is very safe, won't
affect any operations other than delete-to-end, which was broken without the fix:

Index: nsHTMLEditor.cpp
===================================================================
RCS file: /cvsroot/mozilla/editor/base/nsHTMLEditor.cpp,v
retrieving revision 1.332
diff -r1.332 nsHTMLEditor.cpp
2347c2347
<           aAction = eNext;
---
>           aAction = eNone;
No longer depends on: 54452
Whiteboard: [rtm+ → [rtm+] TRIVIAL ONE_LINE FIX IN HAND
(Assignee)

Updated

17 years ago
Target Milestone: Future → M19

Comment 12

17 years ago
outstanding, get in super-reviewed and module owner approval
Whiteboard: [rtm+] TRIVIAL ONE_LINE FIX IN HAND → [rtm+ NEED INFO] TRIVIAL ONE_LINE FIX IN HAND

Comment 13

17 years ago
a = jfrancis

Comment 14

17 years ago
sr=kin

Comment 15

17 years ago
Adding myself to Cc list.
(Assignee)

Updated

17 years ago
Whiteboard: [rtm+ NEED INFO] TRIVIAL ONE_LINE FIX IN HAND → [rtm+ NEED INFO] TRIVIAL R+SR ONE_LINE FIX IN HAND
(Assignee)

Updated

17 years ago
Whiteboard: [rtm+ NEED INFO] TRIVIAL R+SR ONE_LINE FIX IN HAND → [rtm+] TRIVIAL R+SR ONE_LINE FIX IN HAND
(Assignee)

Comment 16

17 years ago
Ah, the reason it was specified as eNext is for delete behavior on empty lines
or at the end of a line.  So it would really be better to keep this fix out, and
fix 54452 instead.  But if we can't fix 54452 in time, this fix is better than
nothing (since people can work around the lack of delete on empty lines by using
^D or backspace instead, whereas there's no workaround for delete-to-end not
working on a nonempty line).

Putting dependency back.
Depends on: 54452

Comment 17

17 years ago
PDT marking RTM++
Whiteboard: [rtm+] TRIVIAL R+SR ONE_LINE FIX IN HAND → [rtm++] TRIVIAL R+SR ONE_LINE FIX IN HAND
(Assignee)

Comment 18

17 years ago
Fix (workaround) checked in.  I'll add a note to 54452 to please undo this
workaround when that bug is fixed (and I so commented in the source).
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 19

17 years ago
verified in 10/10 build.
Status: RESOLVED → VERIFIED
(Assignee)

Comment 20

17 years ago
Note, this bug has come back because the noxif landing accidentally overwrote
the fix.  The fix needs to be checked in again.

Comment 21

17 years ago
Reopen due to merge error between jst and jfrancis
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 22

17 years ago
Fixed again, on branch and trunk.
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED

Comment 23

17 years ago
keybindings are messed up on linux.
is there a workaround for me to verify this bug?

Comment 24

17 years ago
can't verify this until linux keybindings are fixed.

Comment 25

17 years ago
waiting for 57078 to get fixed before verifying
Whiteboard: [rtm++] TRIVIAL R+SR ONE_LINE FIX IN HAND → [rtm++] waiting for 57078 to get fixed before verifying

Comment 26

17 years ago
verified in 10/26 build.
Status: RESOLVED → VERIFIED
Whiteboard: [rtm++] waiting for 57078 to get fixed before verifying → [rtm++]
(Assignee)

Comment 27

17 years ago
Sorry for the spam!  But apparently all these closed bugs need to have their
target milestones changed since M19 and M20 are going away.  Since they're
allready closed, I'm choosing M18.
Target Milestone: M19 → M18
You need to log in before you can comment on or make changes to this bug.