RFR: 8091673: Public focus traversal API for use in custom controls [v3]

[John Hendrikx]

On Tue, 29 Oct 2024 15:21:50 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> What happens when a different type of event is created by a `KeyEvent` handler?  How does the downstream code differentiate between the secondary events coming from a key event handler vs. from one originated normally?
>> 
>>> Is there enough information for the implementation of requestFocusTraversal to know whether it was called from keyboard event?
>> 
>> The (original) intent of this API is to enable the custom components trigger the focus traversal as a response to key events only, the problem is that we can't prevent the application code from misusing the API and calling it for other reason.  (There is no other reason for the application code or custom component to call this method with the `visible=false`, other than misuse)
>> 
>> I would rather specify that this method must be called as a response to KeyEvent, and drop the argument.
>
> That seems reasonable, given that it is the expected use case. I wouldn't say "_must_ be called", but rather that it "is _expected_ to be called" in response to a KeyEvent, and then document the behavior accordingly -- namely, the node that receives focus will be `focusVisible`.
> 
> @mstr2 What do you think?

> What happens when a different type of event is created by a `KeyEvent` handler? How does the downstream code differentiate between the secondary events coming from a key event handler vs. from one originated normally?

This wouldn't matter IMHO, if you fire another event, that just deepens the call stack (the secondary event is fired immediately, not after the key event finishes); the original key event will still be the one that initiated it -- ie. user pressed a key, and focus changed as a result -- no matter how that exactly happened it is then FX's decision to turn on focus visible highlighting.  The whole focus visible highlighting is a feature provided by FX to give it a more native look and feel, but it may be platform dependent which is why I think the user should probably not have a say in the matter. 

I already suggested to make the property writable, but if the user can't be trusted to use it correctly, then they can't be trusted to set such a boolean correctly either.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1604#discussion_r1821134717