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 545282 - [accessibility] the names of items in friends list are not correct
[accessibility] the names of items in friends list are not correct
Status: RESOLVED FIXED
Product: empathy
Classification: Core
Component: General
unspecified
Other All
: Normal normal
: ---
Assigned To: empathy-maint
empathy-maint
: 557010 (view as bug list)
Depends on:
Blocks: 557009
 
 
Reported: 2008-07-29 08:53 UTC by Li Yuan
Modified: 2009-07-27 21:07 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
correctly display contact names in a11y tools (GNOME bug 545282) (1.25 KB, patch)
2009-07-27 16:10 UTC, Frederic Peters
committed Details | Review

Description Li Yuan 2008-07-29 08:53:51 UTC
Start empathy with some accounts enabled (like gtalk). Say there are 4 friends in the list: a, b, c, d. Try to get the accessibility name of the friends, the result will be c, c, c, a or some else orders.
Comment 1 Xavier Claessens 2008-07-29 15:59:34 UTC
I think none of the Empathy developers knows how accessibility works. Please describe in details what needs to be changed in the code. Thanks.
Comment 2 Li Yuan 2008-07-30 03:11:12 UTC
I assume the contact list is gtktreeview. gtktreeview and its accessibility implementation gailtreeview is complicated, it will take time to look at where the bug is. It can be caused by the way that empathy creates and updates gtktreeview. It is also possible that the bug is in gailtreeview.

I will take a look at this when I get time.
Comment 3 Frederic Peters 2008-10-20 08:19:22 UTC
*** Bug 557010 has been marked as a duplicate of this bug. ***
Comment 4 Frederic Peters 2008-10-20 08:20:31 UTC
Adding bug 557009 as blocked by this one, as written in bug 557010.
Comment 5 Nolan Darilek 2008-12-20 16:48:45 UTC
Just wanted to check in and see if anyone has had an opportunity to look into this further?

This morning I installed Empathy 2.25.2 from the Ubuntu PPA. I was pleased to notice that almost everything, including chat, seems to work. The chat could certainly benefit from a bit of Orca scripting but that would be fairly easy to accomplish.

I noticed that this bug is still present, though. Orca only seems to see the last contact on my list, regardless of whether I arrow through the list itself or use its flat review. I'm wondering if somehow the accessibility properties of every item in the view are being set to those of the last item? I don't understand the guts of the accessibility infrastructure either, but that quick-and-dirty explanation would at least be consistent with why I as an Orca user would see my last contact again and again but on-screen the contacts would display correctly.

Also, groups aren't handled correctly, though they're at least different. The group name isn't spoken, but "expanded: tree level 1" is, making me suspect that this might be a quick fix and just a matter of setting the correct property. Group names at least aren't getting incorrect information, just *no* information.

This bug concerns me for a couple reasons. Since Empathy is now the default IM infrastructure for GNOME (IIRC), having the table view accessible seems huge, and my cursory inspection suggests that this is the only major accessibility blocker preventing me at least from replacing pidgin and trying myself to write an Orca script to make Empathy's chat as accessible. Second, since Skype is inaccessible, it'd be cool to offer an easy and mainstream VOIP app as apparently exists via Empathy's Jingle support.

I'm happy to test from Empathy's git repos if anyone is interested in working on this but needs another tester.
Comment 6 Nolan Darilek 2009-01-20 15:53:13 UTC
When I last asked about this bug, I was told that no one really understood how the accessibility infrastructure works from a developer perspective. Does this help?

http://library.gnome.org/devel/accessibility-devel-guide/nightly/
Comment 7 David Bolter 2009-01-20 20:33:46 UTC
(In reply to comment #6)

Hi Nolan,

There are some developers who know the a11y infrastructure including the bug reporter. It is just a matter of having time to fix it and having someone to nag them ;)
Comment 8 Frederic Peters 2009-07-27 09:08:52 UTC
Xavier (or any Empathy developer), I played a little bit with Accerciser and the problem is quite easy to spot, you just have to navigate to the contact list widget where you will see a number of table cells.

They are ordered such as the first ones are the group headers, then all the individual rows, and they are all associated with the name of the last contact.

 * Friends
   * Albert
   * Bernard
 * Foes
   * Christophe
   * Didier

will iterate in the following order: Friends, Foes, Albert, Bernard, Christophe, Didier, and they will all be spoken as "Didier".
Comment 9 Xavier Claessens 2009-07-27 09:25:27 UTC
So that's a orca/accerciser bug? I see nothing we can change in emapthy code...
Comment 10 Nolan Darilek 2009-07-27 14:00:23 UTC
OK, here's something I don't get. For context, I've been a heavy Orca user for years, using it for almost all of my computing. I've done some scripting, written a patch or two and know enough about how it works to be dangerous. I've also heard this "It's Orca/GTK/ATK's issue" claim a few times, with no bug number or other indication as to where the issue lies.

If this is someone else's issue, why do tables in Pidgin, Gajim, Thunderbird, Rhythmbox and just about every other app behave flawlessly, often without Orca doing anything special at all? Yet this contacts table has been broken for years because there's some lurking table bug that doesn't affect anyone else? Please help me understand.

The only other place I've seen behavior remotely similar is in Banshee, which is using both custom widgets and ATK#, which has bugs in its interface to the ATK library itself. They've since resolved their table issues and are working to improve their accessibility. But that wasn't an ATK bug, but rather one in how they provide accessibility information for their custom widgets and widget tweaks.

So what is Empathy doing to revolutionize the table view? And if it can't be done accessibly, then maybe it should be switched back to the standard view until this work can happen, or an option should be put in place to disable whatever awesome features have been added for users needing the accessibility?

I want to be sympathetic to the fact that this is open source and people are often working on these projects in spare time. But it doesn't make sense to me that so many apps' tables work fine, out of the box, and I think Empathy's should be the same. And if they don't then I can't understand how the problem lies anywhere other than with it. Also, accessibility seems important enough such that, if you've discovered an issue in Empathy's interactions with the ATK toolkits, then maybe that interaction should be avoided. And, if there really is a bug somewhere else, and if there's no way for Empathy to behave like every other app in this regard, then maybe that bug should be filed and more effort should be directed that way. IOW, this issue should probably be confirmed and made a higher priority.
Comment 11 Frederic Peters 2009-07-27 14:21:04 UTC
Nolan, I am totally with you here; certainly this behaviour is specific to Empathy and should be fixed there.  However there is no clue in the code on what could cause this, and developers have no experience with the a11y infrastructure.

Ideally someone with gail experience could look at it and provide some hints.
Comment 12 Nolan Darilek 2009-07-27 14:46:16 UTC
Fair enough, I can relate since I'm not terribly familiar with this subsystem either. There are, however, many ways of either getting up to speed with it, or of getting the needed help. Here are some that come to mind:

* I think I posted a link to the accessibility developers' guide earlier in this report.

* There are accessibility and accessibility-devel mailing lists.

* The accessibility channel on irc.gnome.org is usually fairly active.

* The Orca team itself is quite helpful. I've read IRC logs of them working with the webkit folks to get them up to speed. And if they took the time to help developers improve an entire toolkit, they're likely to do something similar for a single issue in an otherwise accessible application, though I certainly can't speak for them. It makes sense, though, since working Empathy access is an Orca 2.28 milestone and they're likely to appreciate having the problem addressed from both ends, as it were.

So, yes, I've heard the one about not understanding the infrastructure and what's going on, and I want to sympathize with it, but there are resources to help with that. If they are being used and haven't turned up anything, then I apologize for being such a nag. If they aren't, though, then they should be, because they represent the most logical next step, and if it doesn't get taken then this bug will still be open next year with everyone either pointing fingers at Orca/GAIL or still not understanding how accessibility works.

Sorry, I really don't enjoy playing the nag, it's just frustrating to see the same basic responses but no indication, in all these months, that anyone has taken a few minutes to ask for help on accessibility-devel or something similar. I'd really like to use Empathy, too, since I really need accessible voice chat, and it's unlikely that Skype will get rewritten using GTK any time soon.



Thanks for your time.
Comment 13 Xavier Claessens 2009-07-27 14:52:57 UTC
Nokan, sorry if I you feel offended, it was not my intention.

"So that's a orca/accerciser bug?", that was a question, not an affirmation. I have absolutely no clue what orca and anything about accessibility does.

If something is wrong in Empathy's code, please give me pointers to what could be the issue... I really have no idea on what to do the fix this bug...

Note that the alias and presence message are displayed with a custom EmpathyCellRendererText widget. It takes 2 strings from the store and concat them with a '\n'. Which makes the alias on top of the presence message effect. With some pango stuff to change the color/size change.
Comment 14 Nolan Darilek 2009-07-27 15:14:25 UTC
No worries, I'm not offended at all.

The issue is that I'm not a C programmer, so am already at a bit of a disadvantage for trying to fix this. For me to learn how the ATK infrastructure works, I'd have to come to grips with C, GLIB, GTK and ATK. Quite a bit to learn, especially for one bug. But those of you working on Empathy already have some familiarity with those technologies, and are likely in a better position to go the last mile than am I, who must run the entire marathon. And, quite frankly, I'm just not smart enough to think in C.

So there's not a whole lot that I, personally, can do to fix this, other than point those who can to the resources there to help them and hope that they can.

So I'm not offended, just a bit bothered that no one seems to have asked for help anywhere other than here, or from anyone other than me. :) Maybe that isn't true, but I know that my periodic "empathy accessibility" googles don't turn up much.

Good luck. Wish I could actually help in a more useful way, but my one attempt to make the contact list accessible just resulted in me renaming the entire table and not the individual rows.
Comment 15 Joanmarie Diggs (IRC: joanie) 2009-07-27 15:50:27 UTC
(In reply to comment #13)
> "So that's a orca/accerciser bug?", that was a question, not an affirmation. I
> have absolutely no clue what orca and anything about accessibility does.

At the risk of sounding anal, it's not an orca/accerciser bug *because* Orca and Accerciser are consistent in what they are presenting. Both apps get their information via the at-spi and only know what they get. We have to trust that what is exposed to us is right. Whether or not the problem lies in some other portion of the accessibility infrastructure (such as Gail) remains to be seen.

> If something is wrong in Empathy's code,

Something very well may be. To be honest, *most* of the time where we see things fall apart is in the use of custom widgets.

HOWEVER, it might be a problem elsewhere. Ekiga's got some goofiness in their contact list (see bug 583597). And as I recall, Esmene does as well. Are all three of these apps creating problems through their respective custom implementations? Could be; or it could be that we're seeing a previously unrecognized problem with fancy treeviews.

> please give me pointers to what could
> be the issue... I really have no idea on what to do the fix this bug...

Man, I wish I knew.... Sorry! What I know is how to work with the stuff that's exposed to us. If you have guesses about how to fix it, I'd happily test any patches and give feedback since I know what I'm expecting to see.
Comment 16 Frederic Peters 2009-07-27 16:10:32 UTC
Created attachment 139294 [details] [review]
correctly display contact names in a11y tools (GNOME bug 545282)
Comment 17 Frederic Peters 2009-07-27 16:14:12 UTC
Xavier: Accerciser is actually a good tool to help developers inspect the a11y situation. (and it's fun!)

Joanmarie, Nolan: I certainly do not know 1) empathy contact list inner working, and 2) the whole a11y infrastructure, but could you test the attached patch, I think it gets the group & contact names correctly.
Comment 18 Xavier Claessens 2009-07-27 17:20:35 UTC
That patch seems fragile because EmatpyhCellRendererText will override that "text" property. But if I get confirmation that it works, then +1 from me.
Comment 19 Joanmarie Diggs (IRC: joanie) 2009-07-27 17:38:52 UTC
I promise to look in a bit. Doing some last-minute 2.27.5 stuff. :-) Thanks guys!!
Comment 20 Joanmarie Diggs (IRC: joanie) 2009-07-27 18:48:49 UTC
(In reply to comment #18)
> That patch seems fragile because EmatpyhCellRendererText will override that
> "text" property. But if I get confirmation that it works, then +1 from me.
> 
So confirmed. Awesomesauce!! 

And buddies coming and going and changing status hasn't busted anything (which I've seen with other problematic treeviews).

+1 as far as I'm concerned. And thanks!!
Comment 21 Nolan Darilek 2009-07-27 19:08:51 UTC
Unfortunately, my only Linux box is a netbook, and I ran out of disk space trying to fetch the various dependencies to test this patch. So I'm glad that we were able to confirm it without me having to figure out how to squeeze more out of this poor tiny SSD. :)

Thanks for this fix! When the binaries containing this patch make it into a PPA, I'll see what I can do about putting together an Empathy script for Orca.

Thanks again!
Comment 22 Xavier Claessens 2009-07-27 20:34:37 UTC
patch accepted then.
Comment 23 Frederic Peters 2009-07-27 21:07:41 UTC
Thanks, pushed as fdd1174c22b2de215c0a4fd0b33051a3b44f5661.