GNOME Bugzilla – Bug 338230
events not consistent in at-spi for gnome-terminal
Last modified: 2006-06-12 14:56:29 UTC
Please describe the problem: As seen by AT-SPI, text events fired by gnome-terminal are inconsistent if delete/backspace has been pressed; inconsistent (essentially inverted) with other gnome applications (eg. gedit). Both event types and ordering are divergent. Also, once <backspace> or <delete> is pressed, gnome-terminal fires different events after each typed character, and maintains this "mode" on all subsequent typing until <CR> resets it. The following show the order of fired events: typing: gterm: moved,inserted events *OR* moved,deleted,inserted gedit: inserted, moved backspace/delete, typing after backspace/delete: gterm: moved, deleted, inserted gedit: deleted, moved Steps to reproduce: 1. run at-poke, don't poke anything, just check "Log events" 2. "Accessible Events" window opens, look in "Events to listen for:", expand "object" and check "text-caret-moved" and "text-changed" events 3. type in GTerminal, watch at-poke's event log 4. type in any other gnome-based editor (eg. gedit), compare the order in each set of fired events 5. compare event types fired when pressing backspace/delete, typing after backspace/delete Actual results: Ordered Events: typing: moved, inserted backspace/delete: moved, deleted, inserted typing after backspace/delete: moved, deleted, inserted Expected results: Ordered Events: typing: inserted, moved backspace/delete: deleted, moved typing after backspace/delete: inserted, moved (don't change after bksp/del) Does this happen every time? yes Other information: This is important for accessibility, since alternate UIs (such as a screen reader) must communicate the cursor changes to the user. If the events are inconsistent, an a11y user might not be given accurate caret information, which will also complicate navigation within a text element. This bug is cross-posted in gnome-terminal, bug# 338104: http://bugzilla.gnome.org/show_bug.cgi?id=338014
Problem is in gnome-terminal's accessibility support code, not in at-spi. *** This bug has been marked as a duplicate of 338014 ***