On Mon, 7 Oct 2024 15:26:16 GMT, John Hendrikx <jhendr...@openjdk.org> wrote:
>> This change modifies `ScrollPaneBehavior` to only consume keys that are
>> targetted at it. As `KeyEvent`s are in almost all cases only intended for
>> the targetted node (as visually that's where the user expects the keyboard
>> input to go, as per normal UI rules) consuming key events that bubble up is
>> simply incorrect. When the `ScrollPane` is focused directly (it has the
>> focused border) then it is fine for it to respond to all kinds of keys.
>>
>> In FX controls normally there is no need to check if a `Control` is focused
>> (although they probably should **all** do this) as they do not have children
>> that could have received the Key Events involved, and Key Events are always
>> sent to the focused Node. When `ScrollPane` was developed this was not
>> taken into account, leading to it consuming keys not intended for it.
>>
>> This fixes several unexpected problems for custom control builders. A
>> custom control normally benefits from standard navigation out of the box
>> (TAB/shift+TAB) and directional keys. However, this breaks down as soon as
>> this custom control is positioned within a `ScrollPane`, which is very
>> surprising behavior and not at all expected. This makes it harder than
>> needed for custom control developers to get the standard navigation for the
>> directional keys, as they would have to specifically capture those keys
>> before they reach the `ScrollPane` and trigger the correct navigation action
>> themselves (for which as of this writing there is no public API).
>>
>> The same goes for all the other keys captured by `ScrollPane` when it does
>> not have focus, although not as critical as the UP/DOWN/LEFT/RIGHT keys.
>
> John Hendrikx has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Add information about how ScrollPane acts on key presses.
modules/javafx.controls/src/main/java/javafx/scene/control/ScrollPane.java line
80:
> 78: * ({@link #isFocused()} returns {@code true}) and won't respond to
> unconsumed
> 79: * key events that bubble up from a focused child control. The key
> presses it
> 80: * acts on are platform specific, but by default should include keys for
> panning
which keys are platform specific? I could not find any - the behavior
registers no platform-specific bindings.
-------------
PR Review Comment: https://git.openjdk.org/jfx/pull/1582#discussion_r1790445619
