On Thu, 12 Mar 2026 23:18:50 GMT, Marius Hanl <[email protected]> wrote:
>> As also discussed back then in the mailing list, there are weird issues
>> around gaining focus when a `Control` is not focus traversable but got a
>> click event.
>>
>> - Some Controls do not call `requestFocus()` when they are not focus
>> traversable and receive a mouse click
>> - It is very inconsistent which Controls do it and which do not. Sometimes,
>> just a part of a `Control` will request focus, while another one will not
>> - Manually calling `requestFocus()` always works
>>
>> It seems like there is a misconception between beeing not focus traversable
>> and not requesting focus. The focus traversable property should only affect
>> keyboard navigation really. A mouse click should always request a focus.
>>
>> Check the Ticket for a reproducer with all `Control`s and a short list which
>> Controls do not behave (and which do).
>>
>> This PR removes the pattern that was wrongly used in some `Control`s.
>> From:
>>
>> if (getNode().isFocusTraversable()) {
>> getNode().requestFocus();
>> }
>>
>> To:
>>
>> getNode().requestFocus();
>
> Marius Hanl has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Remove weird VirtualFlow code.
> ScrollBar should not request focus, as many other Controls do not do that
> when there is no benefit.
> It seems like there is a misconception between beeing not focus traversable
> and not requesting focus. The focus traversable property should only affect
> keyboard navigation really. A mouse click should always request a focus.
Yes, the semantics of `focusTraversable` seem to be a bit unclear. There are
three ways a control can receive focus: with keyboard navigation, with a mouse
click, or programmatically by invoking `Node.requestFocus()`. (There's also the
option of directly calling `setFocused(boolean)`, which I consider to be a
defect and we should seriously consider deprecating this method.)
I don't see a whole lot of value of having a control accept focus with a mouse
click, but not via keyboard navigation. What's the use case here? I would
imagine that if a control is focusable with a mouse click, it should also be
focusable with keyboard navigation.
However, I see quite a bit of value of having a control not accept focus _at
all_, but still be fully functional otherwise. For example, consider a "Copy"
or "Paste" button that act on the currently focused control. It's clear that
such a button can never accept focus, as that would break the intended function.
With your proposed change, a button will always accept focus on click. This
subtly breaks the cut/copy/paste buttons of `HTMLEditor`: they will now steal
the focus, which removes the text cursor from the editor.
I see two ways forward here:
1. We could redefine `focusTraversable` to mean _focusable_, that is, whether
it can accept focus at all.
2. If we want `focusTraversable` to only apply to keyboard navigation, then we
need another `focusable` property that can be used to prevent controls from
stealing focus.
I don't think we can do what you propose and force a control to always accept
focus when clicked, but not accept it when keyboard-traversed. That would be a
functional regression for applications that rely on the non-stealing focus
behavior of buttons.
In any case, we need to discuss this on the mailing list since it affects core
semantics of JavaFX.
-------------
PR Comment: https://git.openjdk.org/jfx/pull/2106#issuecomment-4051052172
