On 6/8/2018 11:38 PM, Sergey Bylokhov wrote:
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.
Ok, then. I'm fine with the fix.
Regards,
Anton.
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.
