RFR: 8277922: Unable to click JCheckBox in JTable through Java Access Bridge [v3]

[Anton Litvinov]

On Wed, 9 Mar 2022 16:11:02 GMT, Anton Litvinov <alitvinov at 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
>
> Anton Litvinov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   The third version of the fix for JDK-8277922

Hello Alexey @aivanov-jdk  and Sergey @mrserb,

The new third version of the fix is created and pushed to the branch of this pull request. The third version of the fix is completely alternative and guaranteed way of resolution of this bug, because of this I would recommend to look at its Full Webrev to simplify understanding of the fix before looking at the exact third commit in GitHub interface. Could you please review the third version of the fix?

In the third fix version I refused from the whole idea to implement the functionality accomplishing click action in BooleanRenderer component, and instead of this decided just to prohibit users to execute any accessible actions on AccessibleContext of BooleanRenderer and to put a point in this controversial bug. Among 6 default table cell renderers in JDK:
- "javax.swing.table.DefaultTableCellRenderer.UIResource"
- "javax.swing.JTable.NumberRenderer"
- "javax.swing.JTable.DoubleRenderer"
- "javax.swing.JTable.DateRenderer"
- "javax.swing.JTable.IconRenderer"
- "javax.swing.JTable.BooleanRenderer"

BooleanRenderer was the only component, whose AccessibleContext had non-null AccessibleAction, however as we see in all research in this bug and this review request, execution of this AccessibleAction of BoleanRenderer did not have any opportunity to change internal states and visual states of the corresponding table cell, so it just never worked. Also Java Access Bridge API for assistive technology software in C++/C, provides only functions to read states and data from accessible table object and does not provide functions for modification of accessible table, therefore implementation of AccessibleAction for BooleanRenderer would create unwanted contradiction in both Java Access Bridge API and Java Accessibility API.

Also recent offline feedback from the bug filer proved that the original approach in 1st and 2nd fix versions was not reliable and proper way of resolution of the bug. Because the main conceptual problem standing behind this bug is not resolvable reliably in current design of Java Access Bridge, which is the fact that 1 or more table cells with Boolean data in them are all associated with a single instance of BooleanRenderer by design of Java Access Bridge, and during execution of "doAccessibleAction(int)" of AccessibleAction of BooleanRenderer the BooleanRenderer HAS NO ANY MEANS to reliably know for which exact cell the user intended to execute the AccessibleAction. Currently each JTable cell has own AccessibleContext object which is instance of "JTable.AccessibleJTable.AccessibleJTableCell" and which internally calls API of AccessibleContext of renderer, but at the same time there is always an opportunity for the end user to get AccessibleContext of the renderer directly bypassing
  API of AccessibleJTable and AccessibleJTableCell, it can be as simple as this
`
TableCellRenderer cellRenderer = table.getCellRenderer(row, column);
if (cellRenderer instanceof Accessible) {
    AccessibleContext cellRendererAc = ((Accessible) cellRenderer).getAccessibleContext();
}
`
, so as soon as the user gets AccessibleContext of BooleanRenderer by any of existing way in Java Access Bridge API or Java Accessibility API, the user has right to call "doAccessibleAction" on it and to expect that it will be worked.

Therefore I am convinced that the only solid way to resolve this bug is to stop reporting to the end users that "AccessibleContext" of "BolleanRenderer" supports "AccessibleAction", what has never been supported in reality.

Thank you,
Anton

-------------

PR: https://git.openjdk.java.net/jdk/pull/7416