Closed Bug 54449 Opened 24 years ago Closed 24 years ago

delete-line sets caret to beginning of document

Categories

(Core :: DOM: Editor, defect, P2)

x86
Linux
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: akkzilla, Assigned: akkzilla)

References

Details

(Keywords: regression, Whiteboard: [rtm++])

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.
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
setting to m19 as this is a pretty big user issue for unix people.  unless 
akkana disagrees?

anthonyd
Target Milestone: --- → M19
there isn't dataloss, but yes it is annoying -- which can wait till after rtm
Whiteboard: [rtm-]
Target Milestone: M19 → Future
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-]
Keywords: 4xp
Priority: P3 → P2
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]
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...
I don't have a fix yet -- I just reported the bug yesterday!
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
Akkana, please include the required information per the rtm checkin rules
Whiteboard: [rtm+ waiting for patch to be attached] → [rtm+ NEED INFO]
- 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+
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
Target Milestone: Future → M19
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
a = jfrancis
sr=kin
Adding myself to Cc list.
Whiteboard: [rtm+ NEED INFO] TRIVIAL ONE_LINE FIX IN HAND → [rtm+ NEED INFO] TRIVIAL R+SR ONE_LINE FIX IN HAND
Whiteboard: [rtm+ NEED INFO] TRIVIAL R+SR ONE_LINE FIX IN HAND → [rtm+] TRIVIAL R+SR ONE_LINE FIX IN HAND
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
PDT marking RTM++
Whiteboard: [rtm+] TRIVIAL R+SR ONE_LINE FIX IN HAND → [rtm++] TRIVIAL R+SR ONE_LINE FIX IN HAND
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
Closed: 24 years ago
Resolution: --- → FIXED
verified in 10/10 build.
Status: RESOLVED → VERIFIED
Note, this bug has come back because the noxif landing accidentally overwrote
the fix.  The fix needs to be checked in again.
Reopen due to merge error between jst and jfrancis
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Fixed again, on branch and trunk.
Status: REOPENED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
keybindings are messed up on linux.
is there a workaround for me to verify this bug?
can't verify this until linux keybindings are fixed.
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
verified in 10/26 build.
Status: RESOLVED → VERIFIED
Whiteboard: [rtm++] waiting for 57078 to get fixed before verifying → [rtm++]
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.