[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    Re: RFR: 4512626: Non-editable JTextArea provides no visual indication of keyboard focus
From:       Alexander Zuev <kizune () openjdk ! org>
Date:       2022-11-29 22:24:35
Message-ID: DPVZPQ9L7m_BHcSrMZD1Uz-9ISCevveos2IMj6_Xa9U=.dc42f363-99c3-4296-b8a3-86439bf8f0fa () github ! com
[Download RAW message or body]

On Tue, 29 Nov 2022 18:19:34 GMT, Phil Race <prr@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


[prev in list] [next in list] [prev in thread] [next in thread]