934875 - Thunderbird: No status bar accessible

Status: VERIFIED FIXED

(Thunderbird :: Disability Access, defect)

Description

[James Teh [:Jamie]]

There doesn't appear to be an accessible for the status bar in Thunderbird any more. The content of the status bar is still accessible, but it's exposed as children of the top level frame instead of beneath a status bar accessible.

The status bar accessible did exist previously. My feeling is that it broke around the time bug 915558 was introduced, but it still exists now that this bug is fixed, which suggests it's not related.

Comment 1

[James Teh [:Jamie]]

Impact: NVDA users can't easily access the status bar in Thunderbird using NVDA's report status bar command.

Comment 2

[alexander :surkov (:asurkov)]

Moving under Thunderbird product until we figure out who is guilty

Comment 3

[Wayne Mery (:wsmwk)]

syshagarwal, do you have a thought of what might have changed here?

Comment 4

[Suyash Agarwal (:sshagarwal)]

Sorry, but this doesn't seem related to my stuff and I don't have any idea otherwise.

Comment 5

[Magnus Melin [:mkmelin]]

Using lighthing? Not bug 935251 by any chance?

Comment 6

[James Teh [:Jamie]]

(In reply to Magnus Melin from comment #5)
> Using lighthing? Not bug 935251 by any chance?
I'm not using Lightning, so this isn't it. :(

Comment 7

[Marco Zehe (:MarcoZ)]

We should get moving on this somehow. What's the XUL of the status bar in TB these days?

Comment 8

[James Teh [:Jamie]]

From what I can see from the code, the status bar is created with the following XUL:
<statusbar class="chromeclass-status" id="status-bar">
I can see this node in the DOM, but an accessible doesn't get created for it. Any ideas as to why this is? Alternatively, any suggestion as to where I can look regarding the rules as to when accessibles get created for XUL elements?

Comment 9

[James Teh [:Jamie]]

Note to self: The relevant XUL is in mail/base/content/mailWindowOverlay.xul.

Comment 10

[Trevor Saunders (:tbsaunde)]

(In reply to James Teh [:Jamie] from comment #8)
> From what I can see from the code, the status bar is created with the
> following XUL:
> <statusbar class="chromeclass-status" id="status-bar">
> I can see this node in the DOM, but an accessible doesn't get created for
> it. Any ideas as to why this is? Alternatively, any suggestion as to where I
> can look regarding the rules as to when accessibles get created for XUL
> elements?

that's odd, http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/general.xml?force=1#130
 should cause there to be a accessible for that.  the logic for creating accessibles lives in nsAccessibilityService::GetOrCreateAccessible() but calling that "rules" is generous.

Comment 11

[James Teh [:Jamie]]

I think I've tracked this down to line 1292 of mozilla/base/accessible/nsAccessibilityService.cpp:
>   } else if (role.EqualsLiteral("xulstatusbar")) {
This should probably be:
  } else if (role.EqualsLiteral("xul:statusbar")) {
I'm still getting my build environment set up, so I'll test this once I get it running. :)

Comment 12

[Trevor Saunders (:tbsaunde)]

(In reply to James Teh [:Jamie] from comment #11)
> I think I've tracked this down to line 1292 of
> mozilla/base/accessible/nsAccessibilityService.cpp:
> >   } else if (role.EqualsLiteral("xulstatusbar")) {
> This should probably be:
>   } else if (role.EqualsLiteral("xul:statusbar")) {
> I'm still getting my build environment set up, so I'll test this once I get
> it running. :)

that's certainly a bug and the right fix for it.  I can't promise it'll work, but it could well be all you need.

Comment 13

[James Teh [:Jamie]]

Attachment: Patch

This patch fixes a typo which prevents accessibles from being created for xul:statusbar. Tested in Thunderbird.

Comment 14

[Marco Zehe (:MarcoZ)]

Comment on attachment 8473181 [details] [diff] [review]
Patch

r=me. Thanks for the patch!

Comment 15

[Marco Zehe (:MarcoZ)]

Landed on jamie's behalf: https://hg.mozilla.org/integration/mozilla-inbound/rev/1b703a57ed36

Thanks for your first Mozilla patch!

Comment 16

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/1b703a57ed36

Comment 17

[James Teh [:Jamie]]

Verified fixed in Thunderbird 35.0a1 (2014-09-02).