After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 727256 - Bogus accessible state-changed:selected events after reaching final result of typeahead search
Bogus accessible state-changed:selected events after reaching final result of...
Status: RESOLVED DUPLICATE of bug 746706
Product: gtk+
Classification: Platform
Component: Accessibility
3.11.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
: 726184 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2014-03-28 16:24 UTC by Joanmarie Diggs (IRC: joanie)
Modified: 2018-02-10 16:12 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
accessible-event listener (351 bytes, text/x-python)
2014-03-28 16:24 UTC, Joanmarie Diggs (IRC: joanie)
Details

Description Joanmarie Diggs (IRC: joanie) 2014-03-28 16:24:24 UTC
Created attachment 273181 [details]
accessible-event listener

Steps to reproduce:
1. Launch the attached accessible-event listener in a terminal
2. Launch gtk3-demo
3. With focus in the demo tree on the left, type "c"
4. Keep pressing Down Arrow to move to the next match

Expected results:
1. object:state-changed:selected events would only be emitted
   when an object's selected state actually changes.
2. the event's detail1 would match the state set

Actual results:
Everything works as expected until the selected item is the final result (in this case "Combo Boxes"). At this point, each time you press Down Arrow, there is a beep indicating that there are no more matches and thus selection is not changing. However:

1. Two object:state-changed:selected events are emitted for "Combo Boxes" each time you press Down Arrow and fail to move.

2. For every event where detail1 is 0 (event announcing the object is unselected), the object continues to have STATE_SELECTED present.

Sample output:
[table cell | Application Class] - event matches state: True
[table cell | Change Display] - event matches state: True
[table cell | Clipboard] - event matches state: True
[table cell | Color Chooser] - event matches state: True
[table cell | Combo Boxes] - event matches state: False
[table cell | Combo Boxes] - event matches state: True
[table cell | Combo Boxes] - event matches state: False
[table cell | Combo Boxes] - event matches state: True
[table cell | Combo Boxes] - event matches state: False
[table cell | Combo Boxes] - event matches state: True
[table cell | Combo Boxes] - event matches state: False
[table cell | Combo Boxes] - event matches state: True
Comment 1 Joanmarie Diggs (IRC: joanie) 2014-03-28 16:27:01 UTC
*** Bug 726184 has been marked as a duplicate of this bug. ***
Comment 2 Matthias Clasen 2018-02-10 05:01:10 UTC
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
Comment 3 Joanmarie Diggs (IRC: joanie) 2018-02-10 16:12:39 UTC
Given the move to gitlab.... Unwanted events from Gtk+ table cells is covered by bug 746706. The states not matching is at least in part related to bug 711397. Going to make this a dup of the former because we already have sufficient dups of the latter to suggest a toolkit-wide examination of states and object:state-changed events is called for.

*** This bug has been marked as a duplicate of bug 746706 ***