the cursor appears to "jump" to beginning of line after i hit backspace --it doesn't really move to the beginning of the line, it just appears there. when i type, entry occurs where expected. found using 2003.02.24.0x comm trunk bits. was not a problem with 2003.02.19.0x bits. this is a problem in mail compose and editor windows. not a problem with html textareas (afaict). 1. open a mail compose or editor window. 2. enter a line of text. 3. hit the backspace (or delete on Mac) key. results: watch the cursor jump to the beginning of the line. 4. type some more text. results: fortunately, text is added to the end of the line, where the cursor really is.
sfraser, is this due to the Leon's caret position caching code that was just checked in?
Assignee: jfrancis → leon.zhang
Blocking 1.4a - no regressions, please.
FYI, the caret position caching change I was referring to above, was part of bug 35296.
Same thing happens in mail/news : see bug 194752. Same cause? Dupe?
*** Bug 194752 has been marked as a duplicate of this bug. ***
I can confirm this in html textareas also when IME (Input Method Editor) is turned on. In this case, problem is serious.
When user type backspace, nsCaret::DrawCaret will call nsTextFrame::GetPointFromOffset (mCachedOffsetValid have been set NS_FALSE.) , whose return value is not correct and mCachedFrameOffset is always (0,0).
Probably a related issue.. I'll open a seperate bug if it is not quite as related as I think. If I try to insert a space at the beginning of a wrapped line the space is correctly placed at the end of the previous line, but the cursor still advances one position. Inserting an additional space will leave the cursor in this position. Text however is inserted at the beginning of the line.
Created attachment 115492 [details] [diff] [review] return to original status walk around this bug temporarily.
Comment on attachment 115492 [details] [diff] [review] return to original status r=brade
Attachment #115492 - Flags: review?(sfraser) → review+
*** Bug 194897 has been marked as a duplicate of this bug. ***
Attachment #115492 - Flags: superreview?(sfraser) → superreview+
I checked in the work-around patch on the TRUNK: mozilla/layout/base/src/nsCaret.cpp revision 1.104 I'm going to reopen bug 35296.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Priority: -- → P1
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.4alpha
*** Bug 194932 has been marked as a duplicate of this bug. ***
*** Bug 194906 has been marked as a duplicate of this bug. ***
*** Bug 195015 has been marked as a duplicate of this bug. ***
*** Bug 195002 has been marked as a duplicate of this bug. ***
*** Bug 195171 has been marked as a duplicate of this bug. ***
*** Bug 195473 has been marked as a duplicate of this bug. ***
vrfy'd fixed with 2003.03.03 trunk bits. whew.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.