Bug 204056

Summary: AX: Implement isolated tree support for math objects
Product: WebKit Reporter: chris fleizach <cfleizach>
Component: AccessibilityAssignee: chris fleizach <cfleizach>
Status: RESOLVED FIXED    
Severity: Normal CC: aboxhall, andresg_22, apinheiro, commit-queue, darin, dmazzoni, ews-watchlist, jcraig, jdiggs, samuel_white, webkit-bug-importer, zalan
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: All   
OS: All   
Attachments:
Description Flags
patch
none
patch
none
patch none

chris fleizach
Reported 2019-11-10 00:09:12 PST
Implement isolated tree support for math objects
Attachments
patch (15.66 KB, patch)
2019-11-10 00:10 PST, chris fleizach
no flags
patch (15.66 KB, patch)
2019-11-10 00:12 PST, chris fleizach
no flags
patch (15.65 KB, patch)
2019-11-13 16:27 PST, chris fleizach
no flags
Radar WebKit Bug Importer
Comment 1 2019-11-10 00:09:21 PST
chris fleizach
Comment 2 2019-11-10 00:10:54 PST
chris fleizach
Comment 3 2019-11-10 00:11:35 PST
Comment on attachment 383238 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=383238&action=review > Source/WebCore/accessibility/isolatedtree/AXIsolatedTreeNode.cpp:-37 > -AXIsolatedObject::AXIsolatedObject(const AXCoreObject& object) Removing the const here because some of the math objects access children() which is non-const
chris fleizach
Comment 4 2019-11-10 00:12:28 PST
chris fleizach
Comment 5 2019-11-11 12:36:36 PST
setProperty(AXPropertyName::HelpText, object.helpTextAttributeValue().isolatedCopy()); + AG: don't think the code style rules state this, but I would prefer (kindly request) blank lines to have zero spaces. Otherwise VO reads "space, space, ..." very annoying. There is an option in Xcode to automatically get rid off trailing spaces, and that does the right thing. - static Ref<AXIsolatedObject> create(const AXCoreObject&); + static Ref<AXIsolatedObject> create(AXCoreObject&); AG: Fine for now. But we should have the create function and the constructor to take an AccessibilityObject, constructor marked as explicit. And a separate copy constructor that takes an AXIsolatedObject. + AXIsolatedObject(AXCoreObject&); + void initializeAttributeData(AXCoreObject&); AG: As in create, we should have an explicit constructor that takes an AccessibilityObject, and a separate copy constructor. initializeAttributeData should take an AccessibilityObject.
chris fleizach
Comment 6 2019-11-13 15:29:09 PST
(In reply to chris fleizach from comment #5) > setProperty(AXPropertyName::HelpText, > object.helpTextAttributeValue().isolatedCopy()); > + > > AG: don't think the code style rules state this, but I would prefer (kindly > request) blank lines to have zero spaces. Otherwise VO reads "space, space, > ..." > very annoying. There is an option in Xcode to automatically get rid off > trailing spaces, and that does the right thing. > > > - static Ref<AXIsolatedObject> create(const AXCoreObject&); > + static Ref<AXIsolatedObject> create(AXCoreObject&); > > AG: Fine for now. But we should have the create function and the constructor > to > take an AccessibilityObject, constructor marked as explicit. And a separate > copy constructor that takes an AXIsolatedObject. > > > + AXIsolatedObject(AXCoreObject&); > + void initializeAttributeData(AXCoreObject&); > > AG: As in create, we should have an explicit constructor that takes an > AccessibilityObject, and a separate copy constructor. initializeAttributeData > should take an AccessibilityObject. Talked with Andres and we discussed at this time we have to deal with the fact that children() is non-const so we need to handle this here because we're calling children() now for the math things
chris fleizach
Comment 7 2019-11-13 16:27:31 PST
WebKit Commit Bot
Comment 8 2019-11-14 07:28:23 PST
Comment on attachment 383513 [details] patch Clearing flags on attachment: 383513 Committed r252457: <https://trac.webkit.org/changeset/252457>
WebKit Commit Bot
Comment 9 2019-11-14 07:28:25 PST
All reviewed patches have been landed. Closing bug.
Darin Adler
Comment 10 2019-11-14 09:05:55 PST
Comment on attachment 383513 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=383513&action=review > Source/WebCore/accessibility/isolatedtree/AXIsolatedTreeNode.cpp:201 > + AXID nodeID = WTF::switchOn(value, > + [&] (Optional<AXID> typedValue) { > + if (!typedValue) > + return InvalidAXID; > + return typedValue.value(); > + }, > + [] (auto&) { return InvalidAXID; } > + ); I don’t understand the reason behind the [&] capture; that mistake seems to be repeated over and over again in the other similar functions. Also maybe we could write this in a way that's a little more readable using valueOr(InvalidAXID). I don’t understand why we have both InvalidAXID and Optional<AXID>; two ways of doing the same thing. We should choose one idiom or the other rather than mixing the two. This here is extra code to translate between them. Indentation mistake here. This return statement should be indented.
chris fleizach
Comment 11 2019-11-14 13:37:22 PST
(In reply to Darin Adler from comment #10) > Comment on attachment 383513 [details] > patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=383513&action=review > > > Source/WebCore/accessibility/isolatedtree/AXIsolatedTreeNode.cpp:201 > > + AXID nodeID = WTF::switchOn(value, > > + [&] (Optional<AXID> typedValue) { > > + if (!typedValue) > > + return InvalidAXID; > > + return typedValue.value(); > > + }, > > + [] (auto&) { return InvalidAXID; } > > + ); > > I don’t understand the reason behind the [&] capture; that mistake seems to > be repeated over and over again in the other similar functions. > > Also maybe we could write this in a way that's a little more readable using > valueOr(InvalidAXID). > > I don’t understand why we have both InvalidAXID and Optional<AXID>; two ways > of doing the same thing. We should choose one idiom or the other rather than > mixing the two. This here is extra code to translate between them. > > Indentation mistake here. This return statement should be indented. Thanks for your feedback. Will look into make those changes
chris fleizach
Comment 12 2019-11-15 10:33:25 PST
> Thanks for your feedback. Will look into make those changes https://bugs.webkit.org/show_bug.cgi?id=204233
Note You need to log in before you can comment on or make changes to this bug.