Summary: | AX: Consider implementing @aria-details. | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | James Craig <jcraig> | ||||||
Component: | Accessibility | Assignee: | Andres Gonzalez <andresg_22> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | Normal | CC: | aboxhall, aleventhal, andresg_22, apinheiro, cfleizach, dmazzoni, ews-watchlist, jdiggs, samuel_white, webkit-bug-importer | ||||||
Priority: | P2 | Keywords: | InRadar | ||||||
Version: | WebKit Nightly Build | ||||||||
Hardware: | All | ||||||||
OS: | All | ||||||||
Attachments: |
|
Description
James Craig
2016-12-13 23:36:37 PST
@aaronlev has posted the most compelling use case so far, for annotations in document suites like Google Docs. IMO, this is worth implementing now. Note that as part of work on ARIA Annotations, the ARIA spec is being updated to allow aria-details to support multiple ids. See w3c/aria#1136 Note the importance of aria-details has increased quite a lot with the ARIA annotations work. Supporting aria-details will be necessary in order to support comments in Google Docs, among other things. W3C ARIA spec issue: https://github.com/w3c/aria/issues/749 Explainer: https://github.com/aleventhal/aria-annotations Also, multiple ids are now supported. See https://github.com/w3c/aria/pull/1136 Luckily, the changeset pointed to in comment 3 already supports multiple ids. But, I think it's only supporting ATK and not AX APIs? Created attachment 424269 [details]
Patch
Comment on attachment 424269 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=424269&action=review > Source/WebCore/accessibility/ios/WebAccessibilityObjectWrapperIOS.mm:1873 > + if (object) { are we ever going to have a case where we have a nil pointer in the vector? won't adding a nil pointer to a vector crash anyway? (In reply to chris fleizach from comment #8) > Comment on attachment 424269 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=424269&action=review > > > Source/WebCore/accessibility/ios/WebAccessibilityObjectWrapperIOS.mm:1873 > > + if (object) { > > are we ever going to have a case where we have a nil pointer in the vector? > won't adding a nil pointer to a vector crash anyway? It is a Vector<RefPtr<>> and it can have null pointers on it. In the current use, it shouldn't have null pointers, but caller can pass null pointers, so I think it is appropriate to check before dereferencing here. Comment on attachment 424269 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=424269&action=review >>> Source/WebCore/accessibility/ios/WebAccessibilityObjectWrapperIOS.mm:1873 >>> + if (object) { >> >> are we ever going to have a case where we have a nil pointer in the vector? won't adding a nil pointer to a vector crash anyway? > > It is a Vector<RefPtr<>> and it can have null pointers on it. In the current use, it shouldn't have null pointers, but caller can pass null pointers, so I think it is appropriate to check before dereferencing here. I think we can save some lines of code if we do if (!object) continue; Created attachment 424276 [details]
Patch
(In reply to chris fleizach from comment #10) > Comment on attachment 424269 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=424269&action=review > > >>> Source/WebCore/accessibility/ios/WebAccessibilityObjectWrapperIOS.mm:1873 > >>> + if (object) { > >> > >> are we ever going to have a case where we have a nil pointer in the vector? won't adding a nil pointer to a vector crash anyway? > > > > It is a Vector<RefPtr<>> and it can have null pointers on it. In the current use, it shouldn't have null pointers, but caller can pass null pointers, so I think it is appropriate to check before dereferencing here. > > I think we can save some lines of code if we do > > if (!object) > continue; Done, agree that is more legible. Committed r275066: <https://commits.webkit.org/r275066> All reviewed patches have been landed. Closing bug and clearing flags on attachment 424276 [details]. |