Bug 117389 - [Windows] Provide MSAA mappings for more WebCore data types
Summary: [Windows] Provide MSAA mappings for more WebCore data types
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Accessibility (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Brent Fulgham
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2013-06-09 20:38 PDT by Brent Fulgham
Modified: 2013-06-11 08:32 PDT (History)
5 users (show)

See Also:


Attachments
Patch (5.37 KB, patch)
2013-06-09 20:40 PDT, Brent Fulgham
no flags Details | Formatted Diff | Diff
Update based on contents of WebAccessibilityObjectWrapperMac.mm to more closely match that behavior. (7.22 KB, patch)
2013-06-10 18:16 PDT, Brent Fulgham
cfleizach: review+
buildbot: commit-queue-
Details | Formatted Diff | Diff
Archive of layout-test-results from webkit-ews-12 for mac-mountainlion-wk2 (640.11 KB, application/zip)
2013-06-10 22:43 PDT, Build Bot
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Brent Fulgham 2013-06-09 20:38:08 PDT
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.
Comment 1 Brent Fulgham 2013-06-09 20:40:24 PDT
Created attachment 204134 [details]
Patch
Comment 2 Brent Fulgham 2013-06-09 20:41:57 PDT
<rdar://problem/12476099>
Comment 3 Brent Fulgham 2013-06-10 18:16:32 PDT
Created attachment 204273 [details]
Update based on contents of WebAccessibilityObjectWrapperMac.mm to more closely match that behavior.
Comment 4 chris fleizach 2013-06-10 18:24:58 PDT
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 5 Build Bot 2013-06-10 22:43:50 PDT
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
Comment 6 Build Bot 2013-06-10 22:43:51 PDT
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
Comment 7 Brent Fulgham 2013-06-10 23:35:10 PDT
Clearly the Mac EWS failure has nothing to do with these changes to Windows-platform specific files.
Comment 8 Brent Fulgham 2013-06-11 08:31:43 PDT
(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.
Comment 9 Brent Fulgham 2013-06-11 08:32:35 PDT
Committed r151440: <http://trac.webkit.org/changeset/151440>