Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060911 Minefield/3.0a1 The sequence of events for pressing "Backspace" in a gtk text field is the following: object:text-changed:deleted (character is removed) object:text-caret-moved (caret moves back one position) The sequence of events for pressing "Delete" in a gtk text field is the following: object:text-changed:deleted (character is removed) (no other event, caret remains where it is) Firefox mimicks the gtk event sequence for "Backspace" but not for "Delete." For "Delete," FF inserts an extra move event: object:text-changed:deleted (character is removed) object:text-caret-moved (caret doesn't actually move, event has same offset as where the caret was previously) For consistency, FF should probably mimick gtk if possible. No move event should be fired since the caret doesn't actually move in the "Delete" case.
Hmm, we might need to have an extra member variable for that. Either a "swallow next caret move event" or a "mLastCaretPosition" to compare with.
Severity: normal → minor
We could store the last caret position and hypertext accessible in nsCaretAccessible, and suppress the caret-move event when it doesn't change.
Note: that would prevent 2 caret move events if the user did something like press Home or End twice in a row. Perhaps that's desirable? It's what I see in gedit.
Created attachment 261831 [details] [diff] [review] Keep track of last node and offset where caret move occured, and don't fire caret move if it hasn't changed (unless there's a selection). Renamed mCurrentDOMNode to mSelectionControllerNode.
Assignee: nobody → aaronleventhal
Status: NEW → ASSIGNED
Attachment #261831 - Flags: review?(ginn.chen)
Created attachment 261835 [details] [diff] [review] Minor correction, same idea
Created attachment 261837 [details] [diff] [review] Perf tweak
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.