Last Comment Bug 288986 - Disabled attribute confusion causing some active XUL elements to be exposed as disabled
: Disabled attribute confusion causing some active XUL elements to be exposed a...
Status: RESOLVED FIXED
: access, sec508
Product: Core
Classification: Components
Component: Disability Access APIs (show other bugs)
: Trunk
: x86 All
: -- normal (vote)
: ---
Assigned To: Aaron Leventhal
:
: alexander :surkov
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-04 10:22 PDT by Aaron Leventhal
Modified: 2006-09-01 06:55 PDT (History)
4 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
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 (5.88 KB, patch)
2005-04-04 10:25 PDT, Aaron Leventhal
neil: superreview+
asa: approval1.8b2+
Details | Diff | Splinter Review

Description Aaron Leventhal 2005-04-04 10:22:38 PDT
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.
Comment 1 Aaron Leventhal 2005-04-04 10:25:36 PDT
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
Comment 2 Aaron Leventhal 2005-04-12 06:28:34 PDT
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.
Comment 3 Aaron Leventhal 2005-04-12 06:31:20 PDT
BTW, Mike Connor agreed to this approach on IRC.
Comment 4 Asa Dotzler [:asa] 2005-04-12 08:15:17 PDT
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
Comment 5 Aaron Leventhal 2005-04-12 08:28:41 PDT
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
Comment 6 neil@parkwaycc.co.uk 2006-09-01 03:11:57 PDT
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 Neil Deakin 2006-09-01 06:55:20 PDT
Neil, see bug 333023 which makes menuitem-base extend control-item.

Note You need to log in before you can comment on or make changes to this bug.