RESOLVED FIXED231766
Calls to AXCoreObject::widget() have to be dispatch to the main thread in isolated tree mode.
https://bugs.webkit.org/show_bug.cgi?id=231766
Summary Calls to AXCoreObject::widget() have to be dispatch to the main thread in iso...
Andres Gonzalez
Reported 2021-10-14 13:16:33 PDT
Calls to AXCoreObject::widget() have to be dispatch to the main thread in isolated tree mode.
Attachments
Patch (13.62 KB, patch)
2021-10-14 13:34 PDT, Andres Gonzalez
no flags
Patch (13.40 KB, patch)
2021-10-14 14:27 PDT, Andres Gonzalez
no flags
Patch (13.46 KB, patch)
2021-10-14 14:41 PDT, Andres Gonzalez
no flags
Patch (13.38 KB, patch)
2021-10-15 05:27 PDT, Andres Gonzalez
no flags
Radar WebKit Bug Importer
Comment 1 2021-10-14 13:16:44 PDT
Andres Gonzalez
Comment 2 2021-10-14 13:34:06 PDT
chris fleizach
Comment 3 2021-10-14 14:00:02 PDT
Comment on attachment 441269 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=441269&action=review > Source/WebCore/accessibility/AccessibilityNodeObject.cpp:804 > + undo > Source/WebCore/accessibility/mac/WebAccessibilityObjectWrapperMac.mm:1680 > + return @[child]; should we return nil if we don't have a child here?
chris fleizach
Comment 4 2021-10-14 14:05:48 PDT
Comment on attachment 441269 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=441269&action=review > Source/WebCore/ChangeLog:13 > + safe and it is created on the main thread. To avoid this problem, We We > we > Source/WebCore/ChangeLog:14 > + have to dispatch those calls to the main thread. Since widget() is call very often now, for every request of the children of a leaf node, added is call > is called
Andres Gonzalez
Comment 5 2021-10-14 14:19:58 PDT
(In reply to chris fleizach from comment #3) > Comment on attachment 441269 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=441269&action=review > > > Source/WebCore/accessibility/AccessibilityNodeObject.cpp:804 > > + > > undo Done. > > > Source/WebCore/accessibility/mac/WebAccessibilityObjectWrapperMac.mm:1680 > > + return @[child]; > > should we return nil if we don't have a child here? I don't believe so because other kinds of Widgets liked ScrollViews and Scrollbars may not have an accessibilityObject but can still return not nil in ALLOW_DEPRECATED_DECLARATIONS_BEGIN return [backingObject->platformWidget() accessibilityAttributeValue:NSAccessibilityChildrenAttribute]; ALLOW_DEPRECATED_DECLARATIONS_END I think accessibilityObject is only for plug-ins, right?
Andres Gonzalez
Comment 6 2021-10-14 14:22:04 PDT
(In reply to chris fleizach from comment #4) > Comment on attachment 441269 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=441269&action=review > > > Source/WebCore/ChangeLog:13 > > + safe and it is created on the main thread. To avoid this problem, We > > We > we > > > Source/WebCore/ChangeLog:14 > > + have to dispatch those calls to the main thread. Since widget() is call very often now, for every request of the children of a leaf node, added > > is call > is called Fixed both, cannot get my grammar straight today :-).
chris fleizach
Comment 7 2021-10-14 14:24:04 PDT
Comment on attachment 441269 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=441269&action=review >>> Source/WebCore/accessibility/mac/WebAccessibilityObjectWrapperMac.mm:1680 >>> + return @[child]; >> >> should we return nil if we don't have a child here? > > I don't believe so because other kinds of Widgets liked ScrollViews and Scrollbars may not have an accessibilityObject but can still return not nil in > > ALLOW_DEPRECATED_DECLARATIONS_BEGIN > return [backingObject->platformWidget() accessibilityAttributeValue:NSAccessibilityChildrenAttribute]; > ALLOW_DEPRECATED_DECLARATIONS_END > > I think accessibilityObject is only for plug-ins, right? I was thinking if isWidget() returns true, but we don't get a widget, does that mean a failure case that we should return from
Andres Gonzalez
Comment 8 2021-10-14 14:27:04 PDT
Created attachment 441282 [details] Patch Addresses Chris's comments.
Andres Gonzalez
Comment 9 2021-10-14 14:41:51 PDT
Created attachment 441288 [details] Patch Modified renderWidgetChildren
Andres Gonzalez
Comment 10 2021-10-14 14:46:35 PDT
(In reply to chris fleizach from comment #7) > Comment on attachment 441269 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=441269&action=review > > >>> Source/WebCore/accessibility/mac/WebAccessibilityObjectWrapperMac.mm:1680 > >>> + return @[child]; > >> > >> should we return nil if we don't have a child here? > > > > I don't believe so because other kinds of Widgets liked ScrollViews and Scrollbars may not have an accessibilityObject but can still return not nil in > > > > ALLOW_DEPRECATED_DECLARATIONS_BEGIN > > return [backingObject->platformWidget() accessibilityAttributeValue:NSAccessibilityChildrenAttribute]; > > ALLOW_DEPRECATED_DECLARATIONS_END > > > > I think accessibilityObject is only for plug-ins, right? > > I was thinking if isWidget() returns true, but we don't get a widget, does > that mean a failure case that we should return from Re-wrote it slightly different that it may be clearer. renderWidgetChildren returns nil for everything that is not a widget. If it is a widget, then we try first the Widget's accessibilityObject, which should be not nil for plug-ins. If that is nil, then we try the platformWidget's AXChildren attribute, which may be not nil for ScrollViews and Scrollbars.
Andres Gonzalez
Comment 11 2021-10-15 05:27:49 PDT
Created attachment 441366 [details] Patch Removing leftover }.
EWS
Comment 12 2021-10-15 12:59:39 PDT
Committed r284266 (243074@main): <https://commits.webkit.org/243074@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 441366 [details].
Note You need to log in before you can comment on or make changes to this bug.