334353 - Duplicate insert/delete events

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[parente]

Chrome text boxes appear to fire duplicate insert/delete events when a key is pressed by the user. For instance, typing 'abc' in the home page text box (Preferences->General->Location(s)) results in the following event stream (assuming it is blank to start):

[event name, char inserted, index, length]

object:text-changed:insert a 0 1
object:text-changed:insert a 0 1
object:text-changed:move a 1
object:text-changed:insert b 1 1
object:text-changed:insert b 1 1
object:text-changed:move b 2
object:text-changed:insert c 2 1
object:text-changed:insert c 2 1
object:text-changed:move c 3

It could be that one of the duplicate events is coming from another, unfocused accessible that is not the text box (maybe the autocomplete dropdown list?). It's really hard to tell since the text box does not properly report STATE_FOCUSED during typing. Fixing bug #334350 might show that this isn't actually a separate bug, but a consequece of that problem.

The ordering of events, though, is consistent with most other gtk applications and should be kept as such.

Comment 1

[Aaron Leventhal]

You're hunch is right. It only happens when the autocomplete popup is open.

Comment 2

[parente]

Then the duplicate event isn't a problem as it's not really a duplicate. We just need to make sure one source has state focused and the other does not, preferably the text box because that's where the user is currently typing. The ones from the combobox can/will be safely ignored.

Comment 3

[Aaron Leventhal]

Will take care of for Firefox 3 -- not a blocker for FF2.

Comment 4

[parente]

> The ones from the combobox can/will be safely ignored.

Er. I meant the ones from the dropdown box (whatever role that is) will be safely ignored.

Comment 5

[Aaron Leventhal]

Actually it turns out that it's not from the combobox.

It's in the textbox, when you go from 0 characters to some characters, or some characters to zero characters. It relates to the fact that an empty document may or may not have a "bogus node" which can be deleted or inserted by the implementation. Pretty ugly, seems like we shouldn't be receiving editor notifications for that.

Comment 6

[Aaron Leventhal]

Attachment: Don't fire events for insertion/removal of meaningless <br>, and don't fire events when it's in a descendant that doesn't affect this text

Comment 7

[Evan Yan]

Comment on attachment 229032 [details] [diff] [review]
Don't fire events for insertion/removal of meaningless <br>, and don't fire events when it's in a descendant that doesn't affect this text

as my testing, when inputting the first character into location bar, no 'text-changed' event fired, because of DOMPointToOffset() failed.

Comment 8

[Aaron Leventhal]

Attachment: 1) Fix forgotten SetEditor() in nsRootAccessible, 2) Fix lack of event for first char typed in empty line (via nsTextFrame change, the layout hadn't been reflowed yet)

Comment 9

[Evan Yan]

Comment on attachment 229663 [details] [diff] [review]
1) Fix forgotten SetEditor() in nsRootAccessible, 2) Fix lack of event for first char typed in empty line (via nsTextFrame change, the layout hadn't been reflowed yet)

r=me

Comment 10

[Aaron Leventhal]

Comment on attachment 229663 [details] [diff] [review]
1) Fix forgotten SetEditor() in nsRootAccessible, 2) Fix lack of event for first char typed in empty line (via nsTextFrame change, the layout hadn't been reflowed yet)

Roc, mainly I need you to look at the layout change.