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 446878 - Orca causes pygtk application to generate GtkWarning messages.
Orca causes pygtk application to generate GtkWarning messages.
Status: RESOLVED FIXED
Product: orca
Classification: Applications
Component: general
2.19.x
Other Linux
: Normal normal
: 2.22.0
Assigned To: Rich Burridge
Orca Maintainers
Depends on: 449757
Blocks:
 
 
Reported: 2007-06-12 20:45 UTC by Rich Burridge
Modified: 2008-07-22 19:33 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
cellrenderer.py (3.97 KB, text/plain)
2007-06-12 20:46 UTC, Rich Burridge
  Details
Patch to fix the problem. (670 bytes, patch)
2007-08-22 20:44 UTC, Rich Burridge
committed Details | Review

Description Rich Burridge 2007-06-12 20:45:39 UTC
Steps to reproduce:

(cellrenderer.py to be attached).

Test #1.

1/ Start "python cellrenderer.py"
2/ Press Space
3/ Press Esc

Results:

Nothing unpleasant.

Test #2.

1/ Start Orca
2/ Start "python cellrenderer.py"
3/ Press Space
4/ Press Esc

Results:

cellrenderer.py:35: GtkWarning: gtk_tree_store_get_path: assertion `iter->user_data != NULL' failed
  gtk.main()

** (cellrenderer.py:10695): WARNING **: get_visible_column_number failed for -1



This is probably a bug in atk/gail, but we got to start somewhere.
Comment 1 Rich Burridge 2007-06-12 20:46:00 UTC
Created attachment 89835 [details]
cellrenderer.py
Comment 2 Willie Walker 2007-06-19 15:30:49 UTC
I wonder if this might be something going wrong in GAIL?  For example, I wonder if it's possible that the GAIL object for the GTK object is hanging onto some iterator when it shouldn't be.
Comment 3 Rich Burridge 2007-06-21 11:24:52 UTC
I've opened bug #449757 against atk/gail for this problem
(and for the Gtk-CRITICAL **: gtk_list_store_get_path: 
assertion `iter->stamp == GTK_LIST_STORE (tree_model)->stamp' 
failed problem).

Marking as "[blocked]".


Comment 4 LiYan.Zhang 2007-08-22 10:08:54 UTC
Possibly, it is Orca which makes some mistakes. In the function of default.py, orca commits some flaws, which exists from the row number 2170 to 2180. The logical flaw is presented as follow:

In this function, when SPACE is pressed in the keyboard, focus moves onto a text, but when ESC is pressed, the focus has been moved to cell. While at present, oldLocusOfFocus.role is text, and oldLocusOfFocus.index=-1. However, Orca considers it as a cell.
Comment 5 Yi Jin 2007-08-22 10:10:43 UTC
In my opinion, orca should test if the oldLocusOfFocus is a cell.

The Trace is:
  • #0 get_visible_column_number
    at gailtreeview.c line 3301
  • #1 gail_tree_view_get_column_at_index
    at gailtreeview.c line 1224
  • #2 atk_table_get_column_at_index
    at atktable.c line 240
  • #3 impl_getColumnAtIndex
    at table.c line 163
  • #4 _ORBIT_skel_small_Accessibility_Table_getColumnAtIndex
    at Accessibility-common.c line 628
  • #5 ??
    from /usr/lib/libORBit-2.so.0
  • #6 ??
  • #7 ??
  • #8 ??
  • #9 ??
  • #10 ??
  • #11 impl_getRowAtIndex
    at table.c line 151
  • #12 ORBit_OAObject_invoke
    from /usr/lib/libORBit-2.so.0
  • #13 ORBit_small_invoke_adaptor
    from /usr/lib/libORBit-2.so.0
  • #14 ??
    from /usr/lib/libORBit-2.so.0
  • #15 ??
  • #16 ??
  • #17 Accessibility_Table__imethods
    from /usr/lib/libspi.so.0
  • #18 ??
  • #19 ??
  • #20 ??
    from /lib/tls/i686/cmov/libc.so.6
  • #21 ??
  • #22 ??
  • #23 ??
    from /lib/tls/i686/cmov/libc.so.6
  • #24 ??

Comment 6 Rich Burridge 2007-08-22 20:44:10 UTC
Created attachment 94148 [details] [review]
Patch to fix the problem.

You are indeed correct. I've created a patch to Orca to
test that the old locus of focus is a table cell before
trying to get the row and column index.

I will now go ahead and commit this to SVN HEAD and the 
gnome-2-20 branch.

Many thanks!
Comment 7 Rich Burridge 2007-08-22 20:53:10 UTC
Patch committed to SVN HEAD and the gnome-2-20 branch. Putting the
bug into "[pending]" state.

Comment 8 Rich Burridge 2007-08-23 00:14:49 UTC
Ack! It looks like oldLocusOfFocus can be None:

oldLocusOfFocus role:  
Traceback (most recent call last):
  • File "/usr/lib/python2.5/site-packages/orca/focus_tracking_presenter.py", line 627 in _processObjectEvent
    s.processObjectEvent(event)
  • File "/usr/lib/python2.5/site-packages/orca/script.py", line 296 in processObjectEvent
    self.listeners[key](event)
  • File "/usr/lib/python2.5/site-packages/orca/scripts/Thunderbird.py", line 127 in onFocus
    orca.setLocusOfFocus(event, acc)
  • File "/usr/lib/python2.5/site-packages/orca/orca.py", line 201 in setLocusOfFocus
    orca_state.locusOfFocus)
  • File "/usr/lib/python2.5/site-packages/orca/focus_tracking_presenter.py", line 938 in locusOfFocusChanged
    newLocusOfFocus)
  • File "/usr/lib/python2.5/site-packages/orca/Gecko.py", line 3811 in locusOfFocusChanged
    newLocusOfFocus)
  • File "/usr/lib/python2.5/site-packages/orca/default.py", line 2170 in locusOfFocusChanged
    print "oldLocusOfFocus role: ", oldLocusOfFocus.role
AttributeError: 'NoneType' object has no attribute 'role'

That means the if clause needs to become:

                if oldParent and oldParent.table and \
                   oldLocusOfFocus and \
                   oldLocusOfFocus.role == rolenames.ROLE_TABLE_CELL:

I'll check in the slightly adjusted default.py's next.
Comment 9 Willie Walker 2007-08-23 13:07:58 UTC
> That means the if clause needs to become:
> 
>                 if oldParent and oldParent.table and \
>                    oldLocusOfFocus and \
>                    oldLocusOfFocus.role == rolenames.ROLE_TABLE_CELL:

I believe oldParent will be None if oldLocusOfFocus is None, so I'm not sure this change is necessary.  I think the problem is just the debug line assuming oldLocusOfFocus is not None:

    "print "oldLocusOfFocus role: ", oldLocusOfFocus.role
Comment 10 Rich Burridge 2007-08-23 14:34:27 UTC
You're right. Okay, I've removed that line from the two default.py's
and committed it. Thanks.
Comment 11 Mike Pedersen 2007-08-29 19:55:29 UTC
I think we've all given this one some testing and it is OK to close.
Comment 12 Rich Burridge 2007-09-04 17:44:30 UTC
Thanks Mike. Closing as FIXED.