On Tue, 29 Nov 2022 18:19:34 GMT, Phil Race <[email protected]> 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

Reply via email to