(In reply to comment #0)
> this is with Orca from SVN trunk.

Is this 100% repeatable?  In addition, do you also see it with the gnome-2-20 branch or just on trunk?

> Is this 100% repeatable?  

Yes.

> In addition, do you also see it with the gnome-2-20
> branch or just on trunk?

Both.

(In reply to comment #2)
> > Is this 100% repeatable?  
> 
> Yes.
> 
> > In addition, do you also see it with the gnome-2-20
> > branch or just on trunk?
> 
> Both.
> 

Thanks!  This definitely looks like something to try to fix by 10-Sep.

> This definitely looks like something to try to fix by 10-Sep.

I'm not sure we are going to be able to fix it. Looks like another pidgin bug.
I added some debug to speechgenerator._getSpeechForTable(). When you
put focus in the tree view in the buddy window, this method is called.

It says it has:

child count:  32

We then try to check each one to see if it has a state of SHOWING
and it craps out on child[2]. The first two are column headers.

child[ 0 ]: name:
child[ 0 ]: role:  table column header
child[ 1 ]: name:
child[ 1 ]: role:  table column header
... traceback ...
Child at index 2 is not an Accessible

If I look at the tree view in pidgin with accerciser, it thinks those
children are:

table column header
table column header
<dead>
table cell
<dead>
table cell
<dead>
...

There is a pair of "<dead>"  and "table cell" entries for each row
of my buddy list.

I'll file another pidgin bug and block this one.

Here's the pidgin ticket url:

http://developer.pidgin.im/ticket/2946#preview

Blocking this bug against it.

In the Orca team meeting today, we discussed putting a try/except around the block inside the for loop in speechgenerator.py:_getSpeechForTable as a defensive move for gnome-2-20.  So, if you can work up patches for trunk and the gnome-2-20 branch, and get Mike to test them with success, we should try to get it in for this Sunday's GNOME 2.20 code freeze. 

Created attachment 94962 [details] [review]
Patch to try to implement what's discussed in comment #6

Not committed yet. I just tried this and I was surprised
to discover that we are still getting a stack trace (this is
at the INFO debug level). It's being nicely caught, and we are
no longer getting the second stack trace and the utterances 
are being returned (see output snippet below).

Will, is this good enough (sans the extra print statement)?
Or should I be looking for also adding in a try:/except: clause
somewhere in atspi.py?

...
BRAILLE LINE:  'pidgin Application Buddy List Frame'
     VISIBLE:  'Buddy List Frame', cursor=1
SPEECH OUTPUT: 'Buddy List frame'
BRAILLE LINE:  'pidgin Application Buddy List Frame TabList  ScrollPane TreeTable'
     VISIBLE:  'TreeTable', cursor=1

+ Trace 160498

GOT BAD CHILD.
SPEECH OUTPUT: ''
SPEECH OUTPUT: 'tree table'
...

> Not committed yet. I just tried this and I was surprised
> to discover that we are still getting a stack trace (this is
> at the INFO debug level). It's being nicely caught, and we are
> no longer getting the second stack trace and the utterances 
> are being returned (see output snippet below).

Ahhh...that's good.  So, the real problem is this:

in _getSpeechForTable
    if child.state.count(atspi.Accessibility.STATE_SHOWING):
AttributeError: 'NoneType' object has no attribute 'state'

If that's the case, then a really simple patch might be to not do the try/except clause, but just do a one-liner patch:

    if child and child.state.count(atspi.Accessibility.STATE_SHOWING):

With this, atspi.py:child() would handle the bogus pidgin behavior, returning None for the child, and the one liner change would handle the None value.

What do you think?

> So, the real problem is this:
>
> in _getSpeechForTable
>    if child.state.count(atspi.Accessibility.STATE_SHOWING):
> AttributeError: 'NoneType' object has no attribute 'state'

That's one of the problems (that was the second traceback).
Are you saying that there is no way to prevent the first traceback?

> If that's the case, then
> ...
> What do you think?

That should give us the same as what we've got (and is cleaner).
I would have thought we should be trying to prevent the first 
traceback though.
 

(In reply to comment #9)
> > So, the real problem is this:
> >
> > in _getSpeechForTable
> >    if child.state.count(atspi.Accessibility.STATE_SHOWING):
> > AttributeError: 'NoneType' object has no attribute 'state'
> 
> That's one of the problems (that was the second traceback).
> Are you saying that there is no way to prevent the first traceback?

It looks like we are handling the first exception in atspi.py:child() and using the traceback information purposely:

        if not newChild:
            # The problem with a child not existing is a bad one.
            # We want to issue a warning and we also want to know
            # where it happens.
            #
            debug.printStack(debug.LEVEL_WARNING)
            debug.println(debug.LEVEL_WARNING,
                          "Child at index %d is not an Accessible" % index)

That is, in order to not just silently swallow the problem and let errant toolkits continue to have these kinds of problems, we output the stack information at LEVEL_WARNING.  LEVEL_WARNING is used to decribe events of interest to end users or system managers or which indicate potential problems, but which Orca can deal with without crashing.

So, I think the simple clean "handle the None" fix is sufficient for our side of things, but we should keep this bug open and [blocked] until the blocker is fixed in pidgin (assuming it really is a problem in pidgin).

Created attachment 95000 [details] [review]
Patch for trunk to prevent second traceback.

Created attachment 95001 [details] [review]
Patch for gnome-2-20 branch to prevent second traceback

Fair enough. Your simple fix works nicely and is much
cleaner. As it's almost a no-brainer, I've committed
the patch to both the gnome-2-20 branch and SVN trunk
and will put this but into a "[pending]" state.

Please test.

Ack. Forgot we were already [blocked]
Guess it doesn't make much sense to be [pending] and [blocked]
so please just test the workaround patch and comment 
if you see any problems. 

Thanks.

I think this might actually be a gail bug.... Or something better addressed by a gail fix.

In my quest to get the %^&*$! expanders and levels made accessible (see bug 395781), I hacked some at gail and some at pidgin and in the process got rid of the dead accessibles by accident.

The trick to making the dead accessibles go away *seems* to be adding a fake/dummy renderer into the invisible column that is set as the expander_column in gtkblist.c's pidgin_blist_show().  What they've apparently done is used the strategy described here: http://scentric.net/tutorial/sec-misc-expander-visibility.html.  They didn't add a renderer for that column because, well, why bother?  So what is happening, as best as I can tell, is that the absence of the renderer is hitting this block of code in gailtreeview.c's gail_tree_view_ref_child():

  /* XXX FIXME: The code below avoids SEGV but it also avoids the issue;
   * probably we should be returning minimally-functional AtkObject instances
   * instead.  See bugzilla.gnome.org #331042.
   */
  if (renderer_list == NULL)
    return NULL;

it returns NULL and dead accessibles show up.

I suppose we *could* ask the Pidgin guys to modify their invisible expander hack by adding another hack....  But perhaps returning a minimally-functional AtkObject would address the problem better -- and do so for other apps that find the tutorial hack....

Just a thought....

Thanks for investigating this further. Adding Li to the CC:
Li, could you please comment of Joanie's findings in comment #14
and tell us whether you think this might be a gail rather than a
pidgin bug.

Thanks.

[Let's try that again].

Thanks for investigating this further. Adding Li to the CC:
Li, could you please comment of Joanie's findings in comment #14
and tell us whether you think this might be a gail rather than a
pidgin bug.

Thanks.

Sounds reasonable to fix in gail. Will make a patch after code freeze.

Please refer to http://bugzilla.gnome.org/show_bug.cgi?id=474504#c7

I can confirm that Li's patch solves the dead accessibles problem.  Thanks Li!

(Am I the only one who thinks "The Dead Accessibles" is a band name just waiting for the right musicians?)

Li, this bug got assigned to you somewhere along the line and your Gail patch fixes it. :-)  I think you can close this one out as well.

OK, thank you!