8208747: [a11y] [macos] In Optionpane Demo, inside ComponentDialog Example, unable to navigate to all items, with VO on #4084
Conversation
…ample, unable to navigate to all items, with VO on Added accessibilityIndex function that correctly returns the index of a child in parent container
|
👋 Welcome back kizune! A progress list of the required criteria for merging this PR into |
|
@azuev-java The following label will be automatically applied to this pull request:
When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command. |
|
The bug is a confidential issue. Either the bug should not be confidential or this review should not be done here. |
I do not see any potential reason why this issue might be confidential. It is not security related, can be reproduced using the readily available demo and affects a large part of functionality. Removing the confidential label from the issue. |
That is what I thought. Anyway, I have done some basic testing and the fix looks fine. It does solve the issue. I will do some more testing and will approve accordingly. |
|
Is there a reason it is not causing an issue in case if JList? JList also has elements inside a container, but I see that we can navigate the elements in JList though there is also one issue that the VO always says "1 on n" (n is total number of elements) on selecting any element of list. I am just wondering why is this only needed for combobox and other components seem to work fine. |
It is by far is not limited with JList. It also affects menu navigation with the accessibility shortcuts - in open menu with AS we can'[t walk past first item. It is particularly bad in JList because traversing trough JList causes a lot of events to be generated such as selection/deselection of the list elements, focus change and such. This causes OS to re-evaluate the current selection by asking either container or child about the current selection index and that is what generates so fierce special effect of multiple selection and selections changing because depending on the order in which system events got populated and developed we update selection in different (but always incorrect) order. |
No I did not mean this. The current bug is about selection issue in combobox. User can not navigate the combobox items using VO using the VO hot Keys and is always stuck on first element. Your change is fixing that error. What I am asking is why the same issue is not observed in JList. Current issue is not present in JList and user can navigate the items using VO in JList. The VO output is always like "1 of n" (n is number of items) and this is also an issue, but I can navigate properly. I think the logic would be similar to navigate in the children and it should not cause issue in one component and not cause issue in other. I have mostly used SwingSet2 and demos from https://docs.oracle.com/javase/tutorial/uiswing/examples/components/index.html to test these 3 components. I am just trying to find if there is something else done in wrong way in Combobox which is correct in JList and Menu. That may be the correct/better approach to this issue. |
In JList it is observed differently because there the multiple selection is allowed and because of that fever events about items selected/deselected and focus change being generated. When we move cursor with the VO hot keys we got selection change events with currently chosen item and the first item in the list, that leads to adding of the chosen item to the selection. That does not change focus and focus event is not being generated but instead of moving cursor we just adjusting selection. But if you will try to move cursor with simple up/down arrows you will see that you can not navigate past second or third item - eventually the order of selection/focus events will bring it back to the beginning of the list. It all starts with the discrepancy between the container reporting which children is selected and the index of the item in parent container reported by the selected children. |
|
@azuev-java This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be: You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 103 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. ➡️ To integrate this PR with the above commit message to the |
|
/integrate |
openjdk
bot
added
integrated
|
@azuev-java Since your change was applied there have been 103 commits pushed to the
Your commit was automatically rebased without conflicts. Pushed as commit 49f622c. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
Added accessibilityIndex function that correctly returns the index of a
child in parent container
Progress
Issue
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/4084/head:pull/4084$ git checkout pull/4084Update a local copy of the PR:
$ git checkout pull/4084$ git pull https://git.openjdk.java.net/jdk pull/4084/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 4084View PR using the GUI difftool:
$ git pr show -t 4084Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/4084.diff