WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
179500
AX: AOM: Implement relation type properties
https://bugs.webkit.org/show_bug.cgi?id=179500
Summary
AX: AOM: Implement relation type properties
Nan Wang
Reported
2017-11-09 11:35:19 PST
AOM Phase 1: Implement relation type properties (aria-activedescendant, etc.). Spec:
https://wicg.github.io/aom/spec/
<
rdar://problem/35077972
>
Attachments
Patch
(34.60 KB, patch)
2017-11-30 18:34 PST
,
Nan Wang
no flags
Details
Formatted Diff
Diff
patch
(34.58 KB, patch)
2017-11-30 18:43 PST
,
Nan Wang
rniwa
: review+
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Nan Wang
Comment 1
2017-11-30 18:34:35 PST
Created
attachment 328063
[details]
Patch
Nan Wang
Comment 2
2017-11-30 18:43:11 PST
Created
attachment 328064
[details]
patch
EWS Watchlist
Comment 3
2017-11-30 18:45:06 PST
Attachment 328064
[details]
did not pass style-queue: ERROR: Tools/WebKitTestRunner/InjectedBundle/AccessibilityUIElement.h:199: 'ariaDetailsElementAtIndex' is incorrectly named. It should be named 'protector' or 'protectedUnsigned'. [readability/naming/protected] [4] ERROR: Tools/WebKitTestRunner/InjectedBundle/AccessibilityUIElement.h:200: 'ariaErrorMessageElementAtIndex' is incorrectly named. It should be named 'protector' or 'protectedUnsigned'. [readability/naming/protected] [4] Total errors found: 2 in 15 files If any of these errors are false positives, please file a bug against check-webkit-style.
Ryosuke Niwa
Comment 4
2017-12-04 13:54:48 PST
Comment on
attachment 328064
[details]
patch View in context:
https://bugs.webkit.org/attachment.cgi?id=328064&action=review
> Source/WebCore/accessibility/AccessibilityObject.cpp:2194 > + auto elements = AccessibleNode::effectiveElementsValueForElement(*element, propertyKey); > + if (elements.size() == 1) > + return elements.first();
What happens when elements contain more than one elements? Should that ever happen? If so, is it really correct to return nullptr in that case? Where is this behavior spec'ed?
> Source/WebCore/accessibility/AccessibilityObject.cpp:3469 > + bool idEmpty = id.isEmpty();
Nit: should be idIsEmpty.
> Source/WebCore/accessibility/AccessibleNode.cpp:337 > +AccessibleNode* AccessibleNode::singleRelationValueForProperty(Element& element, AXPropertyName propertyName)
Please return RefPtr<AccessibleNode> for pointer safety.
> Source/WebCore/accessibility/AccessibleNode.cpp:340 > + if (accessibleNodes.size() == 1)
Is it possible for accessibleNodes to have more than one items? If so, is it really correct to return nullptr. If that's not possible, we should assert that accessibleNodes.size() is either 0 or 1, and this check should instead be replaced by if (accessibleNodes.size()).
> Source/WebCore/accessibility/AccessibleNode.cpp:345 > +Vector<AccessibleNode*> AccessibleNode::relationsValueForProperty(Element& element, AXPropertyName propertyName)
Please return Vector<Ref<AccessibleNode>> instead.
> Source/WebCore/accessibility/AccessibleNode.cpp:353 > +Vector<Element*> AccessibleNode::effectiveElementsValueForElement(Element& element, AXPropertyName propertyName)
Please return Vector<Ref<Element>> instead.
> Source/WebCore/accessibility/AccessibleNode.cpp:383 > +AccessibleNode* AccessibleNode::activeDescendant() const
Please return RefPtr<AccessibleNode>
> Source/WebCore/accessibility/AccessibleNode.cpp:482 > +AccessibleNode* AccessibleNode::details() const
Please return RefPtr<AccessibleNode>
> Source/WebCore/accessibility/AccessibleNode.cpp:498 > +AccessibleNode* AccessibleNode::errorMessage() const
Please return RefPtr<AccessibleNode>
Nan Wang
Comment 5
2017-12-04 14:04:10 PST
Comment on
attachment 328064
[details]
patch View in context:
https://bugs.webkit.org/attachment.cgi?id=328064&action=review
>> Source/WebCore/accessibility/AccessibilityObject.cpp:2194 >> + return elements.first(); > > What happens when elements contain more than one elements? > Should that ever happen? If so, is it really correct to return nullptr in that case? > Where is this behavior spec'ed?
I implemented this as a convenient function for relation types that only contain one AccessibleNode. Maybe we should add an assert here to make sure it only contains one element. The more than one elements case should be addressed in another bug. In that case we could have elementsValueForProperty(property)
https://wicg.github.io/aom/spec/#accessiblenodelist-interface
>> Source/WebCore/accessibility/AccessibleNode.cpp:340 >> + if (accessibleNodes.size() == 1) > > Is it possible for accessibleNodes to have more than one items? If so, is it really correct to return nullptr. > If that's not possible, we should assert that accessibleNodes.size() is either 0 or 1, > and this check should instead be replaced by if (accessibleNodes.size()).
Yes I think an assert here is more appropriate. This is to cover the properties that only should contain one AccessibleNode.
Ryosuke Niwa
Comment 6
2017-12-04 14:06:45 PST
Comment on
attachment 328064
[details]
patch View in context:
https://bugs.webkit.org/attachment.cgi?id=328064&action=review
r=me with the assertion change.
>>> Source/WebCore/accessibility/AccessibilityObject.cpp:2194 >>> + return elements.first(); >> >> What happens when elements contain more than one elements? >> Should that ever happen? If so, is it really correct to return nullptr in that case? >> Where is this behavior spec'ed? > > I implemented this as a convenient function for relation types that only contain one AccessibleNode. Maybe we should add an assert here to make sure it only contains one element. > The more than one elements case should be addressed in another bug. In that case we could have elementsValueForProperty(property) >
https://wicg.github.io/aom/spec/#accessiblenodelist-interface
Okay. Please add an assert to check that there is either 0 or 1 element.
Nan Wang
Comment 7
2017-12-04 17:24:21 PST
Committed
r225511
: <
https://trac.webkit.org/changeset/225511
>
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