Thunderbird: No status bar accessible

VERIFIED FIXED in Thunderbird 34.0

Status

defect
VERIFIED FIXED
6 years ago
5 years ago

People

(Reporter: Jamie, Assigned: Jamie)

Tracking

({regression})

Trunk
Thunderbird 34.0
x86_64
Windows 7
Bug Flags:
in-testsuite +

Thunderbird Tracking Flags

(thunderbird34 fixed)

Details

Attachments

(1 attachment)

Assignee

Description

6 years ago
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.
Assignee

Comment 1

6 years ago
Impact: NVDA users can't easily access the status bar in Thunderbird using NVDA's report status bar command.
Moving under Thunderbird product until we figure out who is guilty
Component: Disability Access APIs → Disability Access
Product: Core → Thunderbird
syshagarwal, do you have a thought of what might have changed here?
Flags: needinfo?(syshagarwal)
Sorry, but this doesn't seem related to my stuff and I don't have any idea otherwise.
Flags: needinfo?(syshagarwal)
Using lighthing? Not bug 935251 by any chance?
Assignee

Comment 6

5 years ago
(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. :(
We should get moving on this somehow. What's the XUL of the status bar in TB these days?
Assignee

Comment 8

5 years ago
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?
Assignee

Comment 9

5 years ago
Note to self: The relevant XUL is in mail/base/content/mailWindowOverlay.xul.
(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.
Assignee

Comment 11

5 years ago
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. :)
(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.
Assignee

Comment 13

5 years ago
Posted patch PatchSplinter Review
This patch fixes a typo which prevents accessibles from being created for xul:statusbar. Tested in Thunderbird.
Landed on jamie's behalf: https://hg.mozilla.org/integration/mozilla-inbound/rev/1b703a57ed36

Thanks for your first Mozilla patch!
Assignee: nobody → jamie
Status: NEW → ASSIGNED
https://hg.mozilla.org/mozilla-central/rev/1b703a57ed36
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 34.0
Assignee

Comment 17

5 years ago
Verified fixed in Thunderbird 35.0a1 (2014-09-02).
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.