I'm not sure what supporting <colorpicker> via MSAA will look like, but it should be something like our <grid> support, using: ROLE_TABLE ROW_COLUMN ROLE_ROW ROLE_CELL Each color needs a name, so we might need to put tooltiptext on the colors in colorpicker.
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla0.9.9
Created attachment 57515 [details] [diff] [review] Tested -- works, but I'm not sure if hyatt will like the code in nsXULElement::HandleEvent(). Is there a better way to ensure the target is set correctly?
Oh yeah, the patch doesn't support rows and columns, just a list of tile children, but that's fine. Looking for reviews.
Keywords: access, fcc508
Whiteboard: need r=, sr=
Created attachment 57569 [details] [diff] [review] Better patch -- tested and works well
Attachment #57515 - Attachment is obsolete: true
Comment on attachment 57569 [details] [diff] [review] Better patch -- tested and works well don't forget we need mcp file changes for this -- new file. remove the comments about reusing the HTML widget in nsAccessibilityService Doesn't the nsFromControlAccessible::GetAccState tell us if we are focused? Why the extra method in the XULColorPicker impl? Just for hover? extra comment in XULColorPickerAcc about being a pushbutton fix these and r=jgaunt
Attachment #57569 - Flags: review+
John, we needed to implement something special for focus because the colorpicker tiles never actually receive NS or DOM focus, similar to menuitems. However, we still need to generate MSAA Focus events. When they're hovered over or arrowed to, it only changes attributes. Therefore, we now generate "DOMMenuActive" events on the items so we can catch where the user's keyboard state of regard is.
-> checked in
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.