GNOME Bugzilla – Bug 346699
Removing row from Gtk Table removes wrong row in ATSPI info
Last modified: 2008-03-20 08:57:11 UTC
Please describe the problem: When removing a row from a GTK Table, the 0th row is removed from the AT-SPI representation, regardless of the actual row number. For example: selection = treeview.get_selection() view, selected = selection.get_selected() model = treeview.get_model() model.remove(selected) If the selected row is row[2], row[0] will be removed Steps to reproduce: 1. run at-poke, go to edit--> preferences --> uncheck "don't poke at descendants marked 'private' " 2. run a gui app including the code above 3. use at-poke to poke/reveal the current children in the treeview 4. trigger the above code to remove one of the non-zero-row children 5. watch as the visual representation is correctly updated 6. close the at-poke window, re-open (refresh doesn't work) and notice that the 0th row entry has been removed, not the child that was actually removed information shown by at-poke Actual results: The 0th row table entry is removed from ATSPI Expected results: The correct row table entry should be removed from ATSPI Does this happen every time? Yes Other information: Is this similar to bug # 346685, where there may have been a failure due to gailcontainercall.c::_gail_container_cell_recompute_child_indices() ??
In comments before "steps to reproduce", there is an error. "If the selected row is row[2], row[0] will be removed" should read "If the selected row is row[2], row[2] will be removed from the treeview but row[0] will be removed from the ATSPI representation".
Although it is probably obvious, I should have noted that the included code was written in Python, and uses the pygtk library.
I have checked this bug by gtk-demo's Editable Cell. the code for deleting a row in this demo is listed below. It is written in c API and I find nothing wrong by observing at-poke, i.e. the row is deleted correctly. I think the code below is the same to the example code which was written in python. I checked this bug under vermillion_61. static void remove_item (GtkWidget *widget, gpointer data) { GtkTreeIter iter; GtkTreeView *treeview = (GtkTreeView *)data; GtkTreeModel *model = gtk_tree_view_get_model (treeview); GtkTreeSelection *selection = gtk_tree_view_get_selection (treeview); if (gtk_tree_selection_get_selected (selection, NULL, &iter)) { gint i; GtkTreePath *path; path = gtk_tree_model_get_path (model, &iter); i = gtk_tree_path_get_indices (path)[0]; gtk_list_store_remove (GTK_LIST_STORE (model), &iter); g_array_remove_index (articles, i); gtk_tree_path_free (path); } }
Hi, Brett, I have ever tried the code above by changing pygtk demo too. And at-poke shows the correct accessible information, i.e. I can not reproduce this bug, would u please try this bug by new version gail again?
Created attachment 90649 [details] python code for testing this bug I use this code to test bug, and i find nothing wrong. Type "python listremove.py" to run it. It is modified through pygtk demo. Please check it.
Adding Eitan who is probably the most familiar with atk/gtk table bugs now.
I couldn't reproduce this bug. Brett, Could you please post the entire test program as an attachment? Also, how are you asserting that row[0] is actually the one being deleted? by the accessible name? contents of text interface?
I am closing this bug, if problem still occurs, just reopen it.