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

[John Hendrikx]

On Mon, 30 Sep 2024 15:31:52 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> SCCE = Self-contained code example, or "complete code sample" in https://wiki.openjdk.org/display/OpenJFX/Submitting+a+Bug+Report

Ah, thank you, I hadn't seen this before.

> I am not entirely convinced that the proposed solution addresses compatibility concerns, unless this can be demonstrated. I would imagine the idea behind SP handling these keys might have been a desire to be able to scroll the content in the view without changing the currently focused node within possibly?

That would be counter to how all scrollable views in almost all UI's work.  Generally, a ScrollPane only scrolls when it has the focus itself.  As an example, in Eclipse, use the Package Explorer and ensure it has a horizonal scroll bar.  Now use the mouse to scroll to the right.  Now press the left arrow key to go "up the tree" and close nodes.  You'll notice that when you are at a root item, and pressing left again will not "bubble" up to the ScrollPane and it starts scrolling left.

At the risk of repeating myself, this is not a matter of what the original programmers may have thought (it is highly likely an oversight, considering how bubbling works and how you don't need to worry about with this in "normal" controls), but what people expect from UI's.  The focused component deals with key presses, and nothing else does.  The only exceptions to these are well understood:

- Menu Hotkeys (usually with a specific kind of menu modifier key as it would otherwise be very confusing)
- Underscored keys to change focus (also only with a modifier, and made visual to the user)
- Navigation
 
> Alternatively, should we use a different set of key bindings instead of simple arrow keys, like for instance alt-ctrl-LEFT/RIGHT/UP/DOWN (option-command-LEFT/RIGHT/UP/DOWN) key bindings, similarly to #1393 ?

That's certainly possible, if that's considered normal for such a control on a given platform.  AFAIK, FX is still doing its best to emulate how controls work on the platforms it supports (as evidenced by specific mac/linux/windows bindings in many behaviors).

On Windows however, I'm not aware of any such bindings.  I've also looked into the Mac platform, and I could not find any combinations that would make the container scroll while another control within it has focus (like an edit box for example).

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

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