Thunderbird: No status bar accessible

VERIFIED FIXED in Thunderbird 34.0

Status

Thunderbird
Disability Access
VERIFIED FIXED
4 years ago
3 years ago

People

(Reporter: Jamie, Assigned: Jamie)

Tracking

({regression})

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

Thunderbird Tracking Flags

(thunderbird34 fixed)

Details

Attachments

(1 attachment)

(Assignee)

Description

4 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

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

Comment 2

4 years ago
Moving under Thunderbird product until we figure out who is guilty
Component: Disability Access APIs → Disability Access
Product: Core → Thunderbird

Comment 3

4 years ago
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)

Comment 5

4 years ago
Using lighthing? Not bug 935251 by any chance?
(Assignee)

Comment 6

4 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

3 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

3 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

3 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

3 years ago
Created attachment 8473181 [details] [diff] [review]
Patch

This patch fixes a typo which prevents accessibles from being created for xul:statusbar. Tested in Thunderbird.
Comment on attachment 8473181 [details] [diff] [review]
Patch

r=me. Thanks for the patch!
Attachment #8473181 - Flags: review+
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
Last Resolved: 3 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 34.0
(Assignee)

Comment 17

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