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 136450 - GTK file chooser breaks accessibility
GTK file chooser breaks accessibility
Status: RESOLVED FIXED
Product: atk
Classification: Platform
Component: atk
git master
Other Linux
: Normal critical
: ---
Assigned To: padraig.obriain
padraig.obriain
AP0
Depends on:
Blocks:
 
 
Reported: 2004-03-07 14:05 UTC by Matthew Garrett
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: 2.5/2.6



Description Matthew Garrett 2004-03-07 14:05:08 UTC
The new GTK file chooser has a hidden treeview widget. Attempting to do
anything to it with the accessibility interface (including asking for a
list of children) results in the application freezing with a large set of
"assertion GTK_WIDGET_REALIZED (tree_view) failed" messages. According to
Owen, I shouldn't be going anywhere near any invisible objects. However,
menu items and toolbar buttons are also missing the VISIBLE status when
queried through ATK, and so simply filtering on that won't work.

This causes fairly major problems for Dasher - if I focus a file chooser
with it, I effectively kill both applications. There should probably be
some mechanism to distinguish between widgets that aren't visible because
they're not being shown, and widgets that aren't visible because they
haven't been realized.
Comment 1 padraig.obriain 2004-03-07 19:59:16 UTC
Does this happen with at-poke and gtk-demo?
Comment 2 bill.haneman 2004-03-07 20:36:44 UTC
An object that is not VISIBLE via ATK still should be queryable, so
Owen may be misunderstanding...  Either gtk+ isn't allowing the atk
implementation to do its job, or the widget shouldn't be exposed via
ATK at all.  My position would be of course that the fact that the
widget is "waiting to be invoked" means that it needs to be exposed
via ATK.

Toolbar buttons ought to have VISIBLE set if they are, indeed, mapped
to the screen.  My recollection is that they do... but perhaps this is
something new in the (new) GtkToolbar that's also broken?
Comment 3 bill.haneman 2004-03-07 20:52:42 UTC
I just confirmed that the GtkFileChooser does fail quite extravagantly
when poked with at-poke.

Comment 4 padraig.obriain 2004-03-07 21:12:59 UTC
What test program did you use?
Comment 5 bill.haneman 2004-03-07 21:17:04 UTC
I used ./testfilechooser in gtk+/tests.  I am assuming that's a
representative example... ?
Comment 6 padraig.obriain 2004-03-07 21:36:55 UTC
The GtkTreeview which is not realized does not have state SHOWING or
VISIBLE set on it.

Is querying this object a bug is the application which is doing the
querying?
Comment 7 bill.haneman 2004-03-07 22:19:12 UTC
no, it's quite usual to query objects without state SHOWING or VISIBLE.
Comment 8 Matthew Garrett 2004-03-07 22:32:29 UTC
I first tripped over this when testing with CVS gedit, so it's not
limited to the GTK demo program
Comment 9 bill.haneman 2004-03-07 22:59:26 UTC
This appears to have been fixed by jrb's commit:

2004-03-06 23:41	jrb 	gtk+/ gtk/ gtkfilechooserdefault.c 	1.117 
38/317  	Sat Mar 6 23:31:18 2004 Jonathan Blandford <jrb@gnome.org>

* gtk/gtkfilechooserdefault.c (struct _GtkFileChooserDefault):
remove unneeded elements.
(tree_selection_changed): removed
(tree_name_data_func): removed
(gtk_file_chooser_default_finalize): don't unref dir model
(create_folder_tree): removed
(get_selection): no longer need to abstract away the selection
function.
(create_file_list): We now create a tree for all actions.
(file_pane_create): Make one tree.
(update_appearance) We really change the mode only, now.

Comment 10 bill.haneman 2004-03-07 23:00:14 UTC
matthew, if Dasher still breaks with the new code, please reopen.