missing property-changed::accessible-name on inbox refresh in Thunderbird

RESOLVED FIXED in mozilla7

Status

()

Core
Disability Access APIs
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: Mike Gorse, Assigned: tbsaunde)

Tracking

(Blocks: 1 bug)

unspecified
mozilla7
All
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:2.0.0) Gecko/20100101 Firefox/4.0
Build Identifier: Thunderbird 3.4a1pre

When the inbox is refreshed in Thunderbird and the number of unread messages changes, the inbox label (and consequently the name of its accessible) changes, but a property-changed::accessible-name is not fired.  This causes problems with Orca and AT-SPI2 since AT-SPI expects to receive the event and continues to read the old cached value (unless AT-SPI 2.0.2 or later is used and setCacheMask is called to disable caching of the name--I plan on proposing that Orca do this for now as a work-around).

As I was testing, I saw the property-changed event being fired when I had the setCacheMask work-around in place but not when I did not have it included, so either this only happens sometimes or the event can be triggered somehow (perhaps calling atk_object_get_name on the accessible triggers the event).  I'm marking this as "happens sometimes" since I'm not entirely sure which is the case.

Reproducible: Sometimes

Steps to Reproduce:
1. Start Orca.  If there is a setCacheMask call in the Thunderbird script, then remove it.
2. Open Thunderbird.
3. Do something to cause the number of unread inbox messages to change.

Actual Results:  
Orca continues to read the old inbox label.

Expected Results:  
I would have expected Thunderbird to send a property-changed::accessible-name when the label gets updated, so Orca would read the new label when it gains focus.  Note that it should also be possible to reproduce this with Accerciser using similar steps.

Comment 1

6 years ago
FWIW, NVDA always picks up the change in unread messages on Windows.

Comment 2

6 years ago
I think we are not handling nsIAccessibleEvent::EVENT_NAME_CHANGE on the atk code.

Comment 3

6 years ago
(In reply to comment #2)
> I think we are not handling nsIAccessibleEvent::EVENT_NAME_CHANGE on the atk
> code.

correct, we could use this event to update atk name (atk_object_set_name), I think this should emit this event automatically.

Fernando, Trevor, can you take it?
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

6 years ago
Blocks: 472809
(Assignee)

Updated

6 years ago
Assignee: nobody → trev.saunders
(Assignee)

Comment 4

6 years ago
Created attachment 539725 [details] [diff] [review]
patch

atk_set_name() sends the proper event for us, so on a name change event we can just see if the name has actually changed and if so set it causing atk to send the signal for us.
Attachment #539725 - Flags: review?(surkov.alexander)

Comment 5

6 years ago
Comment on attachment 539725 [details] [diff] [review]
patch

Review of attachment 539725 [details] [diff] [review]:
-----------------------------------------------------------------

::: accessible/src/atk/nsAccessibleWrap.cpp
@@ +1082,5 @@
> +        nsString newName;
> +        accessible->GetName(newName);
> +        NS_ConvertUTF16toUTF8 utf8Name(newName);
> +        if (!utf8Name.Equals(atkObj->name))
> +          atk_object_set_name(atkObj, utf8Name.get());

does it really make sense to check whether name weren't changed? I'd guess this can happen iff atk name was requested before we handled the event. Do you handle this case?
(Assignee)

Comment 6

6 years ago
(In reply to comment #5)
> Comment on attachment 539725 [details] [diff] [review] [review]
> patch
> 
> Review of attachment 539725 [details] [diff] [review] [review]:
> -----------------------------------------------------------------
> 
> ::: accessible/src/atk/nsAccessibleWrap.cpp
> @@ +1082,5 @@
> > +        nsString newName;
> > +        accessible->GetName(newName);
> > +        NS_ConvertUTF16toUTF8 utf8Name(newName);
> > +        if (!utf8Name.Equals(atkObj->name))
> > +          atk_object_set_name(atkObj, utf8Name.get());
> 
> does it really make sense to check whether name weren't changed? I'd guess
> this can happen iff atk name was requested before we handled the event. Do
> you handle this case?

I think the cost is pretty low, and it ensures that we don't have a race like you describe where we send an event say the name has changed when it actually hasn't.  I'm not sure what you mean by the do you handle this case question.  If your asking why I make the check then I think, if something else not sure.

Comment 7

6 years ago
Comment on attachment 539725 [details] [diff] [review]
patch

ok, r=me
Attachment #539725 - Flags: review?(surkov.alexander) → review+
(Assignee)

Comment 8

6 years ago
http://hg.mozilla.org/mozilla-central/rev/b7a93f1279b7
Severity: minor → normal
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla7

Updated

6 years ago
Depends on: 666337
(Assignee)

Updated

6 years ago
Duplicate of this bug: 493685
You need to log in before you can comment on or make changes to this bug.