On Mon, 7 Oct 2024 15:03:29 GMT, Kevin Rushforth <k...@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: >> >>  >> >>> 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
