<Swing Dev> [11] Review Request: 8202768 [macos] Appkit thread slows when any Window Manager active

[Anton Tarasov]

Hi Sergey,

Is it possible that 'accessibilityAttributeNames' is called not from 
'NSAccessibilityUnignoredAncestor'? In that case it will behave 
differently when the element is ignored. From the other hand, it's 
probably useless to return any attribute except 
'NSAccessibilityParentAttribute' from an ignored element. In scope of 
that, does it make sense to return only 'NSAccessibilityParentAttribute' 
for an ignored element?

Regards,
Anton.

On 6/4/2018 11:57 PM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk11.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8202768
> Webrev: http://cr.openjdk.java.net/~serb/8202768/webrev.00
>
> Short description:
> The root cause of the bug is tremendous complexity of code which 
> iterate over hierarchy of accessibility components, it was added 
> unintentionally in JDK-8145207:
> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/233b59b7ea2f#l8.97
>
> Description:
> Our NSView component implements a accessibilityHitTest() method which 
> is part of accessibility api. When this method is called we need to 
> return the first meaningful  accessibility component: "For example, 
> when you place a button in a window, the system typically creates a 
> button cell inside a button control inside a container view inside a 
> window. Users, however, don’t care about the view hierarchy details. 
> They should only be told that there’s a button in a window. "
>
> To iterate the accessibility components we use 
> NSAccessibilityUnignoredAncestor() method
> https://developer.apple.com/documentation/appkit/1531456-nsaccessibilityunignoredancestor?language=objc 
>
>
> which usually should work in this way:
>   1 Check is the component is ignored, if not then return it.
>   2 If the component is ignored, then request a 
> NSAccessibilityParentAttribute.
>   3 If NSAccessibilityParentAttribute is supported then repeat the 
> step1 for the parent. etc.
>
> But our implementation works in this way:
>   1 Check is the component is ignored, if not then return it.
>   2 If the component is ignored, then request a 
> NSAccessibilityParentAttribute.
>   3 Check that NSAccessibilityParentAttribute is supported. We create 
> a list of all supported attributes in accessibilityAttributeNames() - 
> method which was updated in the fix.
>   4 in the accessibilityAttributeNames() we need to access the parent 
> so we repeat the step 1 for the parent and its parent, and its parent, 
> etc.
>   5 We return back to the first iteration in 
> accessibilityAttributeNames()
>   6 We report that NSAccessibilityParentAttribute is supported(it was 
> requested at step3).
>   7 We return the NSAccessibilityParentAttribute requested at step2.
>   8 Repeat the step 1 until we will found unignored parent.
> (...) some intermediate steps were skipped.
>
>
> As you see at step4 we iterate hierarchy of accessibility components, 
> we do this for each component. So it is quite slow when we have big 
> hierarchy of ignored components.
>
> To block such iteration at step4 I have added a check that it is not 
> necessary to access the parent when we build the list of supported 
> attributes if the current component is "ignored".
>
> Note: The bug can be reproduced on macOS by the testcase when the 
> iSnap is active.
>
>