Summary: | AX: A few control types are returning the wrong answer for isReadOnly | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Dominic Mazzoni <dmazzoni> | ||||||
Component: | Accessibility | Assignee: | Dominic Mazzoni <dmazzoni> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | Normal | CC: | cfleizach, webkit.review.bot | ||||||
Priority: | P2 | ||||||||
Version: | 528+ (Nightly build) | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Attachments: |
|
Description
Dominic Mazzoni
2012-09-14 01:43:33 PDT
Created attachment 164072 [details]
Patch
Comment on attachment 164072 [details]
Patch
isReadOnly is used to determine if canSetValueAttribute is true or false. For many input types, AXValue is writable (on mac) like checkboxes, radio, etc, so I think this will break behavior
Created attachment 164758 [details]
Patch
(In reply to comment #2) > (From update of attachment 164072 [details]) > isReadOnly is used to determine if canSetValueAttribute is true or false. For many input types, AXValue is writable (on mac) like checkboxes, radio, etc, so I think this will break behavior Checkboxes, radio did not have AXValue writable previous - but they should be for a slider or text field. I'm pretty sure this change is just restoring the previous behavior before the latest axnode refactor. I added a Mac test to make it clear what the end result is, and compared those results to the stable build of Safari to confirm that the results are identical. (In reply to comment #4) > (In reply to comment #2) > > (From update of attachment 164072 [details] [details]) > > isReadOnly is used to determine if canSetValueAttribute is true or false. For many input types, AXValue is writable (on mac) like checkboxes, radio, etc, so I think this will break behavior > > Checkboxes, radio did not have AXValue writable previous - but they should be for a slider or text field. > > I'm pretty sure this change is just restoring the previous behavior before the latest axnode refactor. I added a Mac test to make it clear what the end result is, and compared those results to the stable build of Safari to confirm that the results are identical. Thanks for looking into this. I checked on Mac, combo boxes should be writeable and not read only (because you can type into the combo box) it looks like list boxes AXSelectedChildren should be writeable (but not its AXValue) (In reply to comment #5) > I checked on Mac, combo boxes should be writeable and not read only (because you can type into the combo box) Are you sure? This is just for a <select> control, you can't type other than type-ahead. There's no true combo box in html. Either way, is it okay if we land this patch first in order to restore the previous behavior, and then open a new bug with the changes? This will fix a regression in Chromium, and I'd rather get us back to a known-good state first before trying something new. If we make changes to isReadOnly for form controls I may have to make some Chromium changes. - Dominic Comment on attachment 164758 [details] Patch Clearing flags on attachment: 164758 Committed r129036: <http://trac.webkit.org/changeset/129036> All reviewed patches have been landed. Closing bug. |