RFR: 8340852: ScrollPane should not consume navigation keys when it doesn't have direct focus [v2]

[John Hendrikx]

On Mon, 7 Oct 2024 15:03:29 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>>> I said "think of how Shift+Right to extend the selection is implemented in most table views". I never claimed it was handled by the scroll pane or even that it should be. It is typically implemented by allowing an event/action/selector/whatever to bubble up to the enclosing table view to be acted on even if the focus lies on one of its descendants. 
>> 
>> I'm sorry, I misunderstood what you meant here.  This kind of bubbling up is not the problem.  Such events bubble up from the sub-structure of a control (say a table cell) to the table.  The table is still the thing that has focus, which also manages a cursor (the active cell, or the more common cursor in an edit box).  There is no confusion here for users what the focused control is and where input is going, and so it is absolutely fine to let this bubble up to a `Node` that is from a user perspective  "focused" and part of the same control.
>> 
>> This is not the case with `ScrollPane`. Here it clearly bubbles "out" of the focused area to a different control.  If there was a focused box around the entire control (including the scroll bars, like a TableView, TextArea or ListView have) then it is clear to the user where input is going.
>> 
>>> I was just countering this (new) concept that a control shouldn't act on a keystroke unless it has direct focus. That's just not a generally accepted rule.
>> 
>> Perhaps I worded this poorly.  What I always meant to say is a key press should go to the control that has visible focus.  If that control is composed of (to the user irrelevant) other components, then it is fine to let events bubble up within the control and its substructure, as long as the event is not acted upon "outside" the user visible focused area.
>> 
>> Acting on a key press bubbled up from a focused `Button` to a `ScrollPane` would clearly violate this.  The scroll pane does not have visible focus, the button does.
>> 
>> Acting on a key press bubbled up from a table cell doesn't violate this; the `TableView` has the focus (and shows this with a visual cue), the cell is just its cursor and is part of the table view's sub-structure.  Here you can see that the `TableView` has the focused border, and so is free to act on key presses that bubble up to that point:
>> 
>> ![image](https://github.com/user-attachments/assets/fc4b003a-f438-40ca-a511-6fc69f2d56b9)
>> 
>>> If I understand you correctly you're once again citing a new rule, namely that PgUp and PgDn shouldn't allow the focused node to scroll out of view....
>
> @hjohn I now think this does warrant a CSR, if for no other reason than to capture the outcome of this discussion (once it is finished), and any potentially visible behavioral change that a custom control writer might see. Further, it might be helpful to document this in the `ScrollPane` class docs.

@kevinrushforth I've added a paragraph in `ScrollPane`'s javadoc:

> ScrollPane by default only acts on key presses when it has the focus ({@link #isFocused()} returns {@code true}) and won't respond to unconsumed key events that bubble up from a focused child control. The key presses it acts on are platform specific, but by default should include keys for panning and paging the view.

I don't think we should document each key press there (that could be something to document for the specific behavior type if they ever become public).  To compare, `Button` mentions how it works when it is a default or cancel button, but doesn't mention what keys it responds to for general operation.

@kevinrushforth Should the CSR include more than the change in the ScrollPane documentation, like reasoning for the change, and perhaps a code example of how to get the old behavior back (for custom control authors that may have been relying on this behavior)?

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

PR Comment: https://git.openjdk.org/jfx/pull/1582#issuecomment-2397243902
PR Comment: https://git.openjdk.org/jfx/pull/1582#issuecomment-2397249488