Hi, Anton.
On 08/06/2018 07:57, Anton Tarasov wrote:
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?
Yes I think that most of the attributes are not necessary(not used) in
case of "ignored elements". But I do not know for sure which, except
"NSAccessibilityParentAttribute", should remain(like
NSAccessibilityRoleAttribute/NSAccessibilityHelpAttribute or maybe
children related attributes). So I decided to skip any additional
attributes which are not set by default, because default attributes are
cached and should not affect performance.
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.
--
Best regards, Sergey.
