The default bug view has changed. See this FAQ.

Disabled attribute confusion causing some active XUL elements to be exposed as disabled

RESOLVED FIXED

Status

()

Core
Disability Access APIs
RESOLVED FIXED
12 years ago
11 years ago

People

(Reporter: Aaron Leventhal, Assigned: Aaron Leventhal)

Tracking

({access, sec508})

Trunk
x86
All
access, sec508
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

12 years ago
Steps:
Open File->Import Wizard
Click Next
The Back button is now enabled, but it appears disabled in the accessibility
hierarchy

This is due to the fact that the accessibility module uses the same logic for
XUL and HTML disabled attributes. In HTML, disabled="false" actually means
something is disabled, in XUL it means that it is not.
(Assignee)

Comment 1

12 years ago
Created attachment 179592 [details] [diff] [review]
1) General: separate handling of disabled attribute for HTML/XUL in accessibly API impl, 2) Specific: use disabled property in XBL rather than setting attribute
Attachment #179592 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #179592 - Flags: review?(mconnor)

Updated

12 years ago
Attachment #179592 - Flags: superreview?(neil.parkwaycc.co.uk) → superreview+
(Assignee)

Comment 2

12 years ago
Comment on attachment 179592 [details] [diff] [review]
1) General: separate handling of disabled attribute for HTML/XUL in accessibly API impl, 2) Specific: use disabled property in XBL rather than setting attribute

I didn't realize Neil is a peer of toolkit now, so the second r= is not needed.
Attachment #179592 - Flags: review?(mconnor) → approval1.8b2?
(Assignee)

Comment 3

12 years ago
BTW, Mike Connor agreed to this approach on IRC.

Comment 4

12 years ago
Comment on attachment 179592 [details] [diff] [review]
1) General: separate handling of disabled attribute for HTML/XUL in accessibly API impl, 2) Specific: use disabled property in XBL rather than setting attribute

a=asa
Attachment #179592 - Flags: approval1.8b2? → approval1.8b2+
(Assignee)

Comment 5

12 years ago
Checking in accessible/src/base/nsAccessible.cpp;
/cvsroot/mozilla/accessible/src/base/nsAccessible.cpp,v  <--  nsAccessible.cpp
new revision: 1.146; previous revision: 1.145
done
Checking in xpfe/global/resources/content/bindings/tabbrowser.xml;
/cvsroot/mozilla/xpfe/global/resources/content/bindings/tabbrowser.xml,v  <-- 
tabbrowser.xml
new revision: 1.113; previous revision: 1.112
done
Checking in xpfe/global/resources/content/bindings/wizard.xml;
/cvsroot/mozilla/xpfe/global/resources/content/bindings/wizard.xml,v  <-- 
wizard.xml
new revision: 1.24; previous revision: 1.23
done
Checking in toolkit/content/widgets/tabbrowser.xml;
/cvsroot/mozilla/toolkit/content/widgets/tabbrowser.xml,v  <--  tabbrowser.xml
new revision: 1.76; previous revision: 1.75
done
Checking in toolkit/content/widgets/wizard.xml;
/cvsroot/mozilla/toolkit/content/widgets/wizard.xml,v  <--  wizard.xml
new revision: 1.20; previous revision: 1.19
done
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED

Comment 6

11 years ago
Whoops, this caused a regression: we don't currently have a disabled property on menuitems. Enn, should we just make menuitem-base extend control-item? Do we already have a bug for this, or do I need to spin one up? Which branch(es) (if any) do we want it to do this on (this patch predated all branches), and which do we need to back out the tabbrowser changes on?

Comment 7

11 years ago
Neil, see bug 333023 which makes menuitem-base extend control-item.
You need to log in before you can comment on or make changes to this bug.