Steps: 1. Login to yahoo/google/facebook etc 2. Be sure to manually enter password ======================================== Actual: text cursor doesn't follow input. It returns back one position after current character is in text field.

This sounds a little like a repaint problem.

I'm confident that it would cause no trouble fixing

flagging for 2.0 triage. bad perception issue, even though its actually working fine.

Looks like a regression from Bug 581585 The problem is mLastFrameOffset is updated independently from mLastContentOffset, so it is possible for them to lose sync when mLastFrameOffset is changed without mLastContentOffset being updated.

(In reply to comment #4) > Looks like a regression from Bug 581585 > > The problem is mLastFrameOffset is updated independently from > mLastContentOffset, so it is possible for them to lose sync when > mLastFrameOffset is changed without mLastContentOffset being updated. Would you care to elaborate, please? What is exactly happening to cause them get out of sync? Can someone who knows how Fennec creates its password input fields help create a test case please?

(In reply to comment #5) > (In reply to comment #4) > > Looks like a regression from Bug 581585 > > > > The problem is mLastFrameOffset is updated independently from > > mLastContentOffset, so it is possible for them to lose sync when > > mLastFrameOffset is changed without mLastContentOffset being updated. > > Would you care to elaborate, please? What is exactly happening to cause them > get out of sync? > > Can someone who knows how Fennec creates its password input fields help create > a test case please? After some more debugging, seems like it's a combination of problems that causes this bug. I made a test case that reproduces the bug in newer nightlies (tested on Windows and Linux). It simulates what happens in Fennec (in a Fennec password field, letters turn to asterisks after a short delay). It should be run locally and "Remember this decision" should be checked when allowing XPConnect. After pressing Go and waiting two seconds (sometimes you might have to try again to see the bug), the cursor will stay at index 0 even though the real selection is at index 1. You cannot move the cursor to the end by clicking or pressing the right arrow key. If you type in a letter the new letter will appear at the end instead of at the caret position. This bug would be fixed by resolving (or bypassing) any of the following: 1) nsCaret depends on nsISelectionListener for selection change notification, but not all selection changes are notified. For one, if a selected text range is changed through nsIDOMCharacterData, the selection range will adjust automatically but selection listeners are not notified. This causes a discrepancy between the selection and the caret. 2) nsCaret::UpdateCaretPosition would correct any discrepancies between the selection and the caret, but only when the caret is currently drawn. This is why the test case involves a timeout. The bug only appears when the caret is not on screen when the callback code is executed. 3) nsCaret::GetGeometry updates mLastFrame / mLastFrameOffset (through GetCaretFrameForNodeOffset) using the given selection but does not update mLastContent / mLastContentOffset. So if the current offset is different from mLastContentOffset, mLastFrameOffset would become out of sync with mLastContentOffset. On subsequent calls to GetCaretFrameForNodeOffset, if the offset is the same as the old mLastContent, the new (and wrong) frame offset is returned. Seems like the most sensible fix is to update mLastContent in nsCaret::GetGeometry.

FWIW, here's a simple patch that fixes the bug for Fennec. It probably has the least impact among possible solutions.

This is a trial patch to only update mLastFrame(Offset) iff we're updating mLastContent(Offset) as well. I'm still testing the patch to make sure that it doesn't break anything else, but I'm attaching it here for Jim to test it on Fennec.

The patch seems to be fine. I also added a test case for it (which was kind of tricky, but I'm satisfied with the final test).

Comment on attachment 468505 [details] [diff] [review] For check-in http://hg.mozilla.org/mozilla-central/rev/8514be744066

It should be noted that the code parts of this bug was backed out as part of bug 593211, which implemented a better optimization.