Closed Bug 334353 Opened 15 years ago Closed 15 years ago

Duplicate insert/delete events

Categories

(Core :: Disability Access APIs, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: parente, Assigned: aaronlev)

References

Details

(Keywords: access)

Attachments

(2 files)

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.
Blocks: fox2access
You're hunch is right. It only happens when the autocomplete popup is open.
Status: NEW → ASSIGNED
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.
Will take care of for Firefox 3 -- not a blocker for FF2.
No longer blocks: fox2access
Keywords: access
> 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.
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.
Blocks: newatk
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.
Attachment #229032 - Flags: review?(Evan.Yan) → review-
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
Attachment #229663 - Flags: review?(Evan.Yan) → review+
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.
Attachment #229663 - Flags: superreview?(roc)
Attachment #229663 - Flags: superreview?(roc) → superreview+
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.