Several of the WebCore elements exposed through our accessibility layer default to ROLE_SYSTEM_CLIENT, even though there are more specific roles defined in the MSAA documentation (see http://msdn.microsoft.com/en-us/library/windows/desktop/dd373608(v=vs.85).aspx). This patch adds mappings for a number of WebCore types that were not previously being handled.
Created attachment 204134 [details] Patch
<rdar://problem/12476099>
Created attachment 204273 [details] Update based on contents of WebAccessibilityObjectWrapperMac.mm to more closely match that behavior.
Comment on attachment 204273 [details] Update based on contents of WebAccessibilityObjectWrapperMac.mm to more closely match that behavior. View in context: https://bugs.webkit.org/attachment.cgi?id=204273&action=review > Source/WebKit/win/AccessibleBase.cpp:780 > default: do you think we might want to assert or remove the default here. That way someone can take an intelligent look at MSAA roles and choose the right one when new Web roles are added
Comment on attachment 204273 [details] Update based on contents of WebAccessibilityObjectWrapperMac.mm to more closely match that behavior. Attachment 204273 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.appspot.com/results/740503 New failing tests: http/tests/security/cross-origin-plugin-private-browsing-toggled.html
Created attachment 204287 [details] Archive of layout-test-results from webkit-ews-12 for mac-mountainlion-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: webkit-ews-12 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.3
Clearly the Mac EWS failure has nothing to do with these changes to Windows-platform specific files.
(In reply to comment #4) > (From update of attachment 204273 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=204273&action=review > > > Source/WebKit/win/AccessibleBase.cpp:780 > > default: > > do you think we might want to assert or remove the default here. That way someone can take an intelligent look at MSAA roles and choose the right one when new Web roles are added That makes a lot of sense, but I don't think all Web roles are currently covered by the Windows (or Mac) mappings. If we were to add an ASSERT here, I would prefer to make sure we currently map all Web roles to accessibility types so that we start from a known good state.
Committed r151440: <http://trac.webkit.org/changeset/151440>