Closed
Bug 934875
Opened 11 years ago
Closed 10 years ago
Thunderbird: No status bar accessible
Categories
(Thunderbird :: Disability Access, defect)
Tracking
(thunderbird34 fixed)
VERIFIED
FIXED
Thunderbird 34.0
Tracking | Status | |
---|---|---|
thunderbird34 | --- | fixed |
People
(Reporter: Jamie, Assigned: Jamie)
Details
(Keywords: regression)
Attachments
(1 file)
2.09 KB,
patch
|
MarcoZ
:
review+
|
Details | Diff | Splinter Review |
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•11 years ago
|
||
Impact: NVDA users can't easily access the status bar in Thunderbird using NVDA's report status bar command.
Comment 2•11 years ago
|
||
Moving under Thunderbird product until we figure out who is guilty
Component: Disability Access APIs → Disability Access
Product: Core → Thunderbird
Comment 3•11 years ago
|
||
syshagarwal, do you have a thought of what might have changed here?
Flags: needinfo?(syshagarwal)
Comment 4•11 years ago
|
||
Sorry, but this doesn't seem related to my stuff and I don't have any idea otherwise.
Flags: needinfo?(syshagarwal)
Assignee | ||
Comment 6•10 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. :(
Comment 7•10 years ago
|
||
We should get moving on this somehow. What's the XUL of the status bar in TB these days?
Assignee | ||
Comment 8•10 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•10 years ago
|
||
Note to self: The relevant XUL is in mail/base/content/mailWindowOverlay.xul.
Comment 10•10 years ago
|
||
(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•10 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. :)
Comment 12•10 years ago
|
||
(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•10 years ago
|
||
This patch fixes a typo which prevents accessibles from being created for xul:statusbar. Tested in Thunderbird.
Comment 14•10 years ago
|
||
Comment on attachment 8473181 [details] [diff] [review] Patch r=me. Thanks for the patch!
Attachment #8473181 -
Flags: review+
Comment 15•10 years ago
|
||
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
Comment 16•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/1b703a57ed36
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 34.0
Assignee | ||
Comment 17•10 years ago
|
||
Verified fixed in Thunderbird 35.0a1 (2014-09-02).
Status: RESOLVED → VERIFIED
Updated•10 years ago
|
status-thunderbird34:
--- → fixed
You need to log in
before you can comment on or make changes to this bug.
Description
•