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.
setting to m19 as this is a pretty big user issue for unix people. unless akkana disagrees? anthonyd
there isn't dataloss, but yes it is annoying -- which can wait till after rtm
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.
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.
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.
Akkana, please include the required information per the rtm checkin rules
- 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.
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;
outstanding, get in super-reviewed and module owner approval
a = jfrancis
Adding myself to Cc list.
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.
PDT marking RTM++
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).
verified in 10/10 build.
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
Fixed again, on branch and trunk.
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
verified in 10/26 build.
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.