WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
124561
AX: Add AXUIElementCountForSearchPredicate parameterized attribute.
https://bugs.webkit.org/show_bug.cgi?id=124561
Summary
AX: Add AXUIElementCountForSearchPredicate parameterized attribute.
Samuel White
Reported
2013-11-18 22:01:45 PST
WebKit currently supports the AXUIElementsForSearchPredicate parameterized attribute. This lets VoiceOver fetch specific groups of elements very efficiently. However, VoiceOver also needs to support AXUIElementCountForSearchPredicate so it can inform users about the total number of elements that meet their search criteria without actually fetching everything.
Attachments
Patch for EWS.
(35.59 KB, patch)
2013-11-20 10:57 PST
,
Samuel White
eflews.bot
: commit-queue-
Details
Formatted Diff
Diff
Updated patch for EWS.
(37.39 KB, patch)
2013-11-20 11:28 PST
,
Samuel White
eflews.bot
: commit-queue-
Details
Formatted Diff
Diff
Last patch for EWS (I hope).
(39.14 KB, patch)
2013-11-20 12:23 PST
,
Samuel White
buildbot
: commit-queue-
Details
Formatted Diff
Diff
Archive of layout-test-results from webkit-ews-10 for mac-mountainlion-wk2
(486.39 KB, application/zip)
2013-11-20 13:25 PST
,
Build Bot
no flags
Details
Archive of layout-test-results from webkit-ews-05 for mac-mountainlion
(613.75 KB, application/zip)
2013-11-20 15:31 PST
,
Build Bot
no flags
Details
Patch for feedback.
(42.52 KB, patch)
2013-11-20 17:31 PST
,
Samuel White
buildbot
: commit-queue-
Details
Formatted Diff
Diff
Archive of layout-test-results from webkit-ews-12 for mac-mountainlion-wk2
(448.87 KB, application/zip)
2013-11-20 18:26 PST
,
Build Bot
no flags
Details
Patch for review.
(47.14 KB, patch)
2013-11-20 19:41 PST
,
Samuel White
cfleizach
: review+
Details
Formatted Diff
Diff
Updated patch.
(47.06 KB, patch)
2013-12-02 10:54 PST
,
Samuel White
cfleizach
: review+
Details
Formatted Diff
Diff
Final patch.
(47.06 KB, patch)
2013-12-02 11:29 PST
,
Samuel White
no flags
Details
Formatted Diff
Diff
Show Obsolete
(6)
View All
Add attachment
proposed patch, testcase, etc.
Samuel White
Comment 1
2013-11-18 22:09:35 PST
<
rdar://problem/15500340
>
Samuel White
Comment 2
2013-11-20 10:57:57 PST
Created
attachment 217457
[details]
Patch for EWS. No layout test added yet. Just looking for non Mac platform failures via EWS.
EFL EWS Bot
Comment 3
2013-11-20 11:14:06 PST
Comment on
attachment 217457
[details]
Patch for EWS.
Attachment 217457
[details]
did not pass efl-ews (efl): Output:
http://webkit-queues.appspot.com/results/30148019
kov's GTK+ EWS bot
Comment 4
2013-11-20 11:16:34 PST
Comment on
attachment 217457
[details]
Patch for EWS.
Attachment 217457
[details]
did not pass gtk-ews (gtk): Output:
http://webkit-queues.appspot.com/results/29798026
Samuel White
Comment 5
2013-11-20 11:28:11 PST
Created
attachment 217461
[details]
Updated patch for EWS. Should fix non Mac platform issues. Patch not for review. Still needs layout test.
EFL EWS Bot
Comment 6
2013-11-20 11:44:54 PST
Comment on
attachment 217461
[details]
Updated patch for EWS.
Attachment 217461
[details]
did not pass efl-ews (efl): Output:
http://webkit-queues.appspot.com/results/30098033
kov's GTK+ EWS bot
Comment 7
2013-11-20 12:00:14 PST
Comment on
attachment 217461
[details]
Updated patch for EWS.
Attachment 217461
[details]
did not pass gtk-ews (gtk): Output:
http://webkit-queues.appspot.com/results/30798002
Build Bot
Comment 8
2013-11-20 12:13:32 PST
Comment on
attachment 217461
[details]
Updated patch for EWS.
Attachment 217461
[details]
did not pass win-ews (win): Output:
http://webkit-queues.appspot.com/results/30528004
Samuel White
Comment 9
2013-11-20 12:23:36 PST
Created
attachment 217465
[details]
Last patch for EWS (I hope). Missed some DRT fixes. THIS should do it.
Build Bot
Comment 10
2013-11-20 13:25:49 PST
Comment on
attachment 217465
[details]
Last patch for EWS (I hope).
Attachment 217465
[details]
did not pass mac-wk2-ews (mac-wk2): Output:
http://webkit-queues.appspot.com/results/29938032
New failing tests: platform/mac/accessibility/search-predicate-element-count.html
Build Bot
Comment 11
2013-11-20 13:25:51 PST
Created
attachment 217472
[details]
Archive of layout-test-results from webkit-ews-10 for mac-mountainlion-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: webkit-ews-10 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.5
Build Bot
Comment 12
2013-11-20 15:30:58 PST
Comment on
attachment 217465
[details]
Last patch for EWS (I hope).
Attachment 217465
[details]
did not pass mac-ews (mac): Output:
http://webkit-queues.appspot.com/results/30058104
New failing tests: platform/mac/accessibility/search-predicate-element-count.html
Build Bot
Comment 13
2013-11-20 15:31:02 PST
Created
attachment 217485
[details]
Archive of layout-test-results from webkit-ews-05 for mac-mountainlion The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: webkit-ews-05 Port: mac-mountainlion Platform: Mac OS X 10.8.5
chris fleizach
Comment 14
2013-11-20 15:36:41 PST
Comment on
attachment 217465
[details]
Last patch for EWS (I hope). View in context:
https://bugs.webkit.org/attachment.cgi?id=217465&action=review
> Source/WebCore/accessibility/mac/WebAccessibilityObjectWrapperMac.mm:550 > + id searchKeyParameter = [parameterizedAttribute objectForKey:@"AXSearchKey"];
you should start these objects out as the type that they're expected, so we don't have to cast (to CFStringRef), and won't run into any other weird namespace collisions
> Source/WebCore/accessibility/mac/WebAccessibilityObjectWrapperMac.mm:580 > + id searchKey = [searchKeyParameter objectAtIndex:i];
ditto for type
> Source/WebCore/accessibility/mac/WebAccessibilityObjectWrapperMac.mm:582 > + criteria.searchKeys.uncheckedAppend(accessibilitySearchKeyForString((CFStringRef)searchKey));
probably CFStringRef not needed
Samuel White
Comment 15
2013-11-20 17:31:41 PST
Created
attachment 217504
[details]
Patch for feedback. Added layout test to complete patch. Making sure it passes and will update Changelogs.
Build Bot
Comment 16
2013-11-20 18:25:58 PST
Comment on
attachment 217504
[details]
Patch for feedback.
Attachment 217504
[details]
did not pass mac-wk2-ews (mac-wk2): Output:
http://webkit-queues.appspot.com/results/30578040
New failing tests: platform/mac/accessibility/search-predicate-element-count.html
Build Bot
Comment 17
2013-11-20 18:26:00 PST
Created
attachment 217512
[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.5
Samuel White
Comment 18
2013-11-20 19:41:49 PST
Created
attachment 217514
[details]
Patch for review.
Samuel White
Comment 19
2013-11-20 19:48:31 PST
(In reply to
comment #14
)
> (From update of
attachment 217465
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=217465&action=review
> > > Source/WebCore/accessibility/mac/WebAccessibilityObjectWrapperMac.mm:550 > > + id searchKeyParameter = [parameterizedAttribute objectForKey:@"AXSearchKey"]; > > you should start these objects out as the type that they're expected, so we don't have to cast (to CFStringRef), and won't run into any other weird namespace collisions
The object referenced by each pointer is validated with isKindOfClass: before being messaged so collisions aren't an issue for us here. However, your suggestion helps with readability so I've included it.
> > > Source/WebCore/accessibility/mac/WebAccessibilityObjectWrapperMac.mm:580 > > + id searchKey = [searchKeyParameter objectAtIndex:i]; > > ditto for type > > > Source/WebCore/accessibility/mac/WebAccessibilityObjectWrapperMac.mm:582 > > + criteria.searchKeys.uncheckedAppend(accessibilitySearchKeyForString((CFStringRef)searchKey)); > > probably CFStringRef not needed
I thought these casts made the somewhat tricky CFStringRef/String backing clearer. Since I've followed your above advice, this became redundant. Removed. Thanks.
Samuel White
Comment 20
2013-11-20 19:51:35 PST
(In reply to
comment #19
)
> (In reply to
comment #14
) > > (From update of
attachment 217465
[details]
[details]) > > View in context:
https://bugs.webkit.org/attachment.cgi?id=217465&action=review
> > > > > Source/WebCore/accessibility/mac/WebAccessibilityObjectWrapperMac.mm:550 > > > + id searchKeyParameter = [parameterizedAttribute objectForKey:@"AXSearchKey"]; > > > > you should start these objects out as the type that they're expected, so we don't have to cast (to CFStringRef), and won't run into any other weird namespace collisions > > The object referenced by each pointer is validated with isKindOfClass: before being messaged so collisions aren't an issue for us here. However, your suggestion helps with readability so I've included it. > > > > > > Source/WebCore/accessibility/mac/WebAccessibilityObjectWrapperMac.mm:580 > > > + id searchKey = [searchKeyParameter objectAtIndex:i]; > > > > ditto for type > > > > > Source/WebCore/accessibility/mac/WebAccessibilityObjectWrapperMac.mm:582 > > > + criteria.searchKeys.uncheckedAppend(accessibilitySearchKeyForString((CFStringRef)searchKey)); > > > > probably CFStringRef not needed > > I thought these casts made the somewhat tricky CFStringRef/String backing clearer. Since I've followed your above advice, this became redundant. Removed.
Oops, to clarify, I meant this cast: searchText = (CFStringRef)searchTextParameter; As the relationship between String type and CFStringRef type is non obvious (imo). the others were legacy.
> > Thanks.
Samuel White
Comment 21
2013-11-24 15:16:15 PST
Any additional feedback on this one Chris?
chris fleizach
Comment 22
2013-11-30 15:23:04 PST
Comment on
attachment 217514
[details]
Patch for review. View in context:
https://bugs.webkit.org/attachment.cgi?id=217514&action=review
> Tools/DumpRenderTree/mac/AccessibilityUIElementMac.mm:200 > + NSMutableDictionary* parameterizedAttribute = [NSMutableDictionary dictionary];
this * should be on the other side since it's an ObjC object
> Tools/DumpRenderTree/mac/AccessibilityUIElementMac.mm:213 > + if (searchKeyString) {
braces not necessary since it's a single line
> Tools/DumpRenderTree/mac/AccessibilityUIElementMac.mm:1017 > + NSDictionary* parameterizedAttribute = searchPredicateParameterizedAttributeForSearchCriteria(context, startElement, isDirectionNext, UINT_MAX, searchKey, searchText, visibleOnly);
* on wrong side
> Tools/DumpRenderTree/mac/AccessibilityUIElementMac.mm:1029 > + NSDictionary* parameterizedAttribute = searchPredicateParameterizedAttributeForSearchCriteria(context, startElement, isDirectionNext, 1, searchKey, searchText, visibleOnly);
* on wrong side
> Tools/WebKitTestRunner/InjectedBundle/mac/AccessibilityUIElementMac.mm:215 > + NSMutableDictionary* parameterizedAttribute = [NSMutableDictionary dictionary];
* on wrong side
> Tools/WebKitTestRunner/InjectedBundle/mac/AccessibilityUIElementMac.mm:228 > + if (searchKeyString) {
braces not necessary
> Tools/WebKitTestRunner/InjectedBundle/mac/AccessibilityUIElementMac.mm:1046 > + NSDictionary* parameterizedAttribute = searchPredicateParameterizedAttributeForSearchCriteria(context, startElement, isDirectionNext, UINT_MAX, searchKey, searchText, visibleOnly);
* on wrong side
> Tools/WebKitTestRunner/InjectedBundle/mac/AccessibilityUIElementMac.mm:1058 > + NSDictionary* parameterizedAttribute = searchPredicateParameterizedAttributeForSearchCriteria(context, startElement, isDirectionNext, 1, searchKey, searchText, visibleOnly);
* on wrong side
Samuel White
Comment 23
2013-12-02 10:54:57 PST
Created
attachment 218189
[details]
Updated patch.
Samuel White
Comment 24
2013-12-02 10:59:40 PST
(In reply to
comment #22
)
> (From update of
attachment 217514
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=217514&action=review
> > > Tools/DumpRenderTree/mac/AccessibilityUIElementMac.mm:200 > > + NSMutableDictionary* parameterizedAttribute = [NSMutableDictionary dictionary]; > > this * should be on the other side since it's an ObjC object > > > Tools/DumpRenderTree/mac/AccessibilityUIElementMac.mm:213 > > + if (searchKeyString) { > > braces not necessary since it's a single line
Fixed.
> > > Tools/DumpRenderTree/mac/AccessibilityUIElementMac.mm:1017 > > + NSDictionary* parameterizedAttribute = searchPredicateParameterizedAttributeForSearchCriteria(context, startElement, isDirectionNext, UINT_MAX, searchKey, searchText, visibleOnly); > > * on wrong side > > > Tools/DumpRenderTree/mac/AccessibilityUIElementMac.mm:1029 > > + NSDictionary* parameterizedAttribute = searchPredicateParameterizedAttributeForSearchCriteria(context, startElement, isDirectionNext, 1, searchKey, searchText, visibleOnly); > > * on wrong side > > > Tools/WebKitTestRunner/InjectedBundle/mac/AccessibilityUIElementMac.mm:215 > > + NSMutableDictionary* parameterizedAttribute = [NSMutableDictionary dictionary]; > > * on wrong side > > > Tools/WebKitTestRunner/InjectedBundle/mac/AccessibilityUIElementMac.mm:228 > > + if (searchKeyString) { > > braces not necessary
Fixed.
> > > Tools/WebKitTestRunner/InjectedBundle/mac/AccessibilityUIElementMac.mm:1046 > > + NSDictionary* parameterizedAttribute = searchPredicateParameterizedAttributeForSearchCriteria(context, startElement, isDirectionNext, UINT_MAX, searchKey, searchText, visibleOnly); > > * on wrong side > > > Tools/WebKitTestRunner/InjectedBundle/mac/AccessibilityUIElementMac.mm:1058 > > + NSDictionary* parameterizedAttribute = searchPredicateParameterizedAttributeForSearchCriteria(context, startElement, isDirectionNext, 1, searchKey, searchText, visibleOnly); > > * on wrong side
Why are we considering "NSString* str" wrong and "NSString *str" correct? If I look at the files you mention, the vast majority of our obj-c code is of the style "NSString* str". Is this something you hope to change moving forward? If so, I can adopt this style per your request. Thanks.
chris fleizach
Comment 25
2013-12-02 11:08:43 PST
(In reply to
comment #24
)
> (In reply to
comment #22
) > > (From update of
attachment 217514
[details]
[details]) > > View in context:
https://bugs.webkit.org/attachment.cgi?id=217514&action=review
> > > > > Tools/DumpRenderTree/mac/AccessibilityUIElementMac.mm:200 > > > + NSMutableDictionary* parameterizedAttribute = [NSMutableDictionary dictionary]; > > > > this * should be on the other side since it's an ObjC object > > > > > Tools/DumpRenderTree/mac/AccessibilityUIElementMac.mm:213 > > > + if (searchKeyString) { > > > > braces not necessary since it's a single line > > Fixed. > > > > > > Tools/DumpRenderTree/mac/AccessibilityUIElementMac.mm:1017 > > > + NSDictionary* parameterizedAttribute = searchPredicateParameterizedAttributeForSearchCriteria(context, startElement, isDirectionNext, UINT_MAX, searchKey, searchText, visibleOnly); > > > > * on wrong side > > > > > Tools/DumpRenderTree/mac/AccessibilityUIElementMac.mm:1029 > > > + NSDictionary* parameterizedAttribute = searchPredicateParameterizedAttributeForSearchCriteria(context, startElement, isDirectionNext, 1, searchKey, searchText, visibleOnly); > > > > * on wrong side > > > > > Tools/WebKitTestRunner/InjectedBundle/mac/AccessibilityUIElementMac.mm:215 > > > + NSMutableDictionary* parameterizedAttribute = [NSMutableDictionary dictionary]; > > > > * on wrong side > > > > > Tools/WebKitTestRunner/InjectedBundle/mac/AccessibilityUIElementMac.mm:228 > > > + if (searchKeyString) { > > > > braces not necessary > > Fixed. > > > > > > Tools/WebKitTestRunner/InjectedBundle/mac/AccessibilityUIElementMac.mm:1046 > > > + NSDictionary* parameterizedAttribute = searchPredicateParameterizedAttributeForSearchCriteria(context, startElement, isDirectionNext, UINT_MAX, searchKey, searchText, visibleOnly); > > > > * on wrong side > > > > > Tools/WebKitTestRunner/InjectedBundle/mac/AccessibilityUIElementMac.mm:1058 > > > + NSDictionary* parameterizedAttribute = searchPredicateParameterizedAttributeForSearchCriteria(context, startElement, isDirectionNext, 1, searchKey, searchText, visibleOnly); > > > > * on wrong side > > Why are we considering "NSString* str" wrong and "NSString *str" correct? If I look at the files you mention, the vast majority of our obj-c code is of the style "NSString* str". Is this something you hope to change moving forward? If so, I can adopt this style per your request. Thanks.
For objectiveC objects it should be like "NSString *a" -- a lot of code doesn't conform to this standard, but i guess for code we touch we should slowly start to move them into correct form --------------- Under Pointer & Referneces
http://www.webkit.org/coding/coding-style.html
Pointer types in non-C++ code — Pointer types should be written with a space between the type and the * (so the * is adjacent to the following identifier if any). [pointers-non-cpp] ---------------------
Samuel White
Comment 26
2013-12-02 11:29:40 PST
Created
attachment 218198
[details]
Final patch. Moved * in every file being compiled as obj-c++ to meet spec. Chris mentioned. Should be ready to go. Thanks.
Samuel White
Comment 27
2013-12-02 11:37:21 PST
Comment on
attachment 218198
[details]
Final patch. Will commit manually if all tests pass.
Samuel White
Comment 28
2013-12-02 16:37:12 PST
Committed in
http://trac.webkit.org/changeset/159980
Closing.
Alexey Proskuryakov
Comment 29
2013-12-03 14:21:10 PST
platform/mac/accessibility/search-predicate-element-count.html is failing on all OS X versions. I'm going to roll out soon, unless someone speaks up, because this affects EWS reliability.
Samuel White
Comment 30
2013-12-03 14:28:16 PST
(In reply to
comment #29
)
> platform/mac/accessibility/search-predicate-element-count.html is failing on all OS X versions. I'm going to roll out soon, unless someone speaks up, because this affects EWS reliability.
The test only fails when run in a group. I suggest we mark it as flaky until I can get to the bottom o fit.
Alexey Proskuryakov
Comment 31
2013-12-03 15:18:57 PST
OK, marked as flaky, and filed
bug 125195
to track this.
Samuel White
Comment 32
2013-12-03 15:20:26 PST
(In reply to
comment #31
)
> OK, marked as flaky, and filed
bug 125195
to track this.
Great, thank you.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug