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 677347 - The accessible name of the 'Lock'/'Unlock' button is always 'Lock'
The accessible name of the 'Lock'/'Unlock' button is always 'Lock'
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: Other
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2012-06-02 18:20 UTC by Joanmarie Diggs (IRC: joanie)
Modified: 2012-07-09 01:13 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
event listener (448 bytes, text/plain)
2012-06-02 18:20 UTC, Joanmarie Diggs (IRC: joanie)
Details

Description Joanmarie Diggs (IRC: joanie) 2012-06-02 18:20:58 UTC
Created attachment 215496 [details]
event listener

Steps to reproduce:

1. Launch the attached listener in a terminal window.

2. Interact with the 'Lock'/'Unlock' button (e.g. in User Accounts or in Date and Time): Give it focus, press it, cause its displayed label to change, etc.

Expected results: The accessible name would reflect the on-screen text.

Actual results: The accessible name is always 'Lock'. Furthermore, there do not seem to be any property-change events which might signal to an AT (or to AT-SPI2) that the name has changed.

Impact: An AT (e.g. Orca) presenting the button always presents it as the 'Lock' button. An AT making it possible to interact with widgets via speech recognition + AT-SPI2 will not be able to support clicking on the 'Unlock' button.
Comment 1 Matthias Clasen 2012-06-05 11:23:17 UTC
thats a gtk widget
Comment 2 Benjamin Otte (Company) 2012-06-15 15:43:05 UTC
Not an easy fix for this.

Button accessibles are defined to not have any children (who did that?) and to use the text of the first label found with a depth-first search (why?) in its children as the name. One could change this to look for a visible label only, but that would not get you change notifications. In general, this approach does not allow change notifications without a lot of redesign inside GTK.

Now, one could special-case this for GtkLockButton, but that would require writing a new accessible. And because GtkLockButton is a regular GtkButton (why?) it seems to allow adding custom child widgets (should it?)

So I'm not sure why all this stuff behaves that way at all and what the proper fix is.
Comment 3 Joanmarie Diggs (IRC: joanie) 2012-06-15 18:15:20 UTC
(In reply to comment #2)
> Not an easy fix for this.
> 
> Button accessibles are defined to not have any children (who did that?)

:)

> children as the name. One could change this to look for a visible label only,
> but that would not get you change notifications.

Personally, I'm less concerned about the notifications. I was merely pointing that out since I happened to notice it. The must-have results for me is what I identified in the opening report as "expected."

> In general, this approach does
> not allow change notifications without a lot of redesign inside GTK.

How much work would it take to cause the accessible name to reflect the displayed text without a change notification?
Comment 4 Matthias Clasen 2012-06-15 21:43:12 UTC
Here is the minimal patch that makes get_name return "Unlock" when appropriate.
As Benjamin said, no change notification. And it seems that orca is caching the value ? At least, it keeps saying Unlock, after I unlocked the button, which changed the label to "Lock".

diff --git a/gtk/a11y/gtkbuttonaccessible.c b/gtk/a11y/gtkbuttonaccessible.c
index d0b9d16..d9fab26 100644
--- a/gtk/a11y/gtkbuttonaccessible.c
+++ b/gtk/a11y/gtkbuttonaccessible.c
@@ -99,7 +99,8 @@ find_label_child (GtkContainer *container)
   child = NULL;
   for (tmp_list = children; tmp_list != NULL; tmp_list = tmp_list->next)
     {
-      if (GTK_IS_LABEL (tmp_list->data))
+      if (GTK_IS_LABEL (tmp_list->data) &&
+          gtk_widget_get_visible (GTK_WIDGET (tmp_list->data)))
         {
           child = GTK_WIDGET (tmp_list->data);
           break;
Comment 5 Joanmarie Diggs (IRC: joanie) 2012-06-15 22:05:08 UTC
(In reply to comment #4)
> Here is the minimal patch that makes get_name return "Unlock" when appropriate.
> As Benjamin said, no change notification. And it seems that orca is caching the
> value ?

Or AT-SPI2 is caching it on Orca's behalf. Orca does very little caching of its own, and what little it does do it dumps extremely often. Nonetheless, I'll take a look soon. 

In the meantime, I assume that when you use the listener from the opening report, the correct name is printed each time focus is given to the button?
Comment 6 Benjamin Otte (Company) 2012-07-09 01:13:38 UTC
I've pushed a set of patches to master that fixes this. Or rather: The supplied test works now. I tested it against tests/testlockbutton.