RFR: 4512626: Non-editable JTextArea provides no visual indication of keyboard focus

[Alexander Zuev]

On Tue, 29 Nov 2022 18:19:34 GMT, Phil Race <prr at openjdk.org> wrote:

> Hmm. This is a pretty broad change. It applies to any Swing component that accepts a caret as far as I can tell, and is broader than A11Y, so I worry about unexpected consequences. What is the situation today for a JTextField - and other such components ?

They are also affected in the same way.

> Why was the bug report mentioning only JTextArea ?

The bug was reported during the VPAT certification of the JCK suite. They use a lot of JTextArea for the testing instructions and looks like that is what caught attention of the A11Y office. Would they notice the JTextField issue they would've report that too.

> What happens for AWT heavyweights?

Same. They are affected by the issue too.

> Does Windows display a caret even if they aren't editable ? 

You mean native Windows controls? I have to check it out - and not only on Windows. However that would not affect our A11Y certification.

> Why is a non-editable Text Area really any different than a JLabel ?? Surely that can't get focus ? I guess I am surprised that that a non-editable component should have focus at all .. so what other components accept focus even if they aren't "active" ?

Have to check other components but JLabel can not receive focus while non-editable JTextArea and JTextField can. Moreover - the caret is active, you can move it and when editable status changes the caret will be in a new position. If you move it with shift pressed - you can select text and with corresponding shortcuts you can copy that selected text to the clipboard.

> My general questions need to be addressed first, but after we get past that you need to revisit this code. It seems to overlook that an application could change the blink rate itself, and restores the saved rate over what the application has set.

Ok, the only way it can be a problem is when user will try to set the blink rate of the uneditable component's caret. I think i will have to special-case that.

> Also, SFAICT setBlinkRate() doesn't seem to be preventing negative values ...

I wonder what will happen if i set a negative rate. Will it blink into the past before component is even created? Can it cause a time paradox? Hmm.

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

PR: https://git.openjdk.org/jdk/pull/11408