On Thu, 10 Feb 2022 04:59:33 GMT, Anton Litvinov <alitvi...@openjdk.org> wrote:
> Hello,
>
> Could you please review the following fix for the bug. The bug consists in
> the fact that When an assistive technology software by means of Java Access
> Bridge API executes "AccessibleAction" "click" on "AccessibleContext" which
> corresponds to "javax.swing.JTable" cell containing "javax.swing.JCheckBox",
> then the cell's value and cell's view represented by "JCheckBox" stay
> unchanged. The issue is a bug in JDK and should be fixed in JDK, because JDK
> informs the assistive technology software through Java Access Bridge API in
> particular through the function
>
> "BOOL getAccessibleActions(long vmID, AccessibleContext accessibleContext,
> AccessibleActions *actions)"
>
> that "AccessibleContext" of the table cell with "JCheckBox" supports one
> action "click", while real execution of this action on this accessible
> context does not lead to any result.
>
> THE ROOT CAUSE OF THE BUG:
>
> The reason of the issue is the fact that when the assistive technology
> software tries to do "AccessibleAction" on "AccessibleContext" associated
> with a cell with boolean data type in "JTable" component through Java Access
> Bridge (JAB), the JDK executes this "AccessibleAction" on "AccessibleContext"
> of a renderer, which is an instance of the class
> "javax.swing.JTable.BooleanRenderer" which is a derivative of "JCheckBox"
> class, and the instance of this renderer is single and common for all cells
> of boolean data type. Therefore execution of "click" "AccessibleAction" on
> this renderer component which is not permanently bound to any particular cell
> in the table does not lead to update of the table cell value.
>
> THE FIX:
>
> The fix implements an approach which guarantees setting of new values to the
> table's cells with boolean data type on each execution of "AccessibleAction"
> of "javax.swing.JTable.BooleanRenderer" instance, when execution of this
> action changes the "selected" state of this "BooleanRenderer" JCheckBox
> component.
>
> Please take into account that the created automatic regression test simulates
> the issue only with Java Accessibility API what is not fully equal to the
> original test scenario which requires the assistive technology software and
> usage of Java Access Bridge API and which can be tested using the manual test
> case attached to the issue in JBS. However the regression test still allows
> to reproduce the issue and verify that the fix resolves it.
>
> Thank you,
> Anton
src/java.desktop/share/classes/javax/swing/JTable.java line 5493:
> 5491: }
> 5492:
> 5493: protected class AccessibleBooleanRenderer
I guess the doAccessibleAction(i); should work in a similar way as something
like "table,getCellJComponent()".click(). Is it actually possible to click on
the cell w/o using robot and w/o a11y API just via Swing API and w/o adding
code for each type of the renderer?
src/java.desktop/share/classes/javax/swing/JTable.java line 5508:
> 5506: (table != null) && table.isEnabled() &&
> 5507: table.isCellEditable(row, column)) {
> 5508: table.setValueAt(Boolean.valueOf(newSelectedState),
Where this code is triggered if the user click on the checkbox by the mouse?
test/jdk/javax/accessibility/JTable/JCheckBoxInJTableCannotBeClickedTest.java
line 92:
> 90:
> 91: private void createGUI() {
> 92: if (!(UIManager.getLookAndFeel() instanceof MetalLookAndFeel)) {
Why the metal L&F is tested, should at least any default L&F works(like Aqua)?
-------------
PR: https://git.openjdk.java.net/jdk/pull/7416
