352205 - Caret move event after text delete without actually moving caret

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[parente]

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.

Comment 1

[Aaron Leventhal]

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.

Comment 2

[Aaron Leventhal]

We could store the last caret position and hypertext accessible in nsCaretAccessible, and suppress the caret-move event when it doesn't change.

Comment 3

[Aaron Leventhal]

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.

Comment 4

[Aaron Leventhal]

Attachment: 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.

Comment 5

[Aaron Leventhal]

Attachment: Minor correction, same idea

Comment 6

[Aaron Leventhal]

Attachment: Perf tweak