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

[John Hendrikx]

On Wed, 2 Oct 2024 21:12:07 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> I played a bit more with your example. Your CustomButtonSkin is weird as it does not place the original button in the scene graph, not sure if that's important.

I think there is a misunderstanding.  The `CustomButton` **is** part of the scene graph (it's added by the user).  It is after all the container in which the Skin is placing the controls that give this custom control its appearance.  The easiest way to give it an appearance is to add a Text or Label, which I did.  Adding the Node provided to the Skin to the scene graph again (instead of things like shapes, texts, labels, etc) would create a cycle (and FX wil throw an immediate exception :-) )

The structure is:

     CustomButton (situated in a container somewhere in the Scene, added by the user to the scene graph)
        |
        --> Label (displaying the button text, added by the Skin)

The default skins work similar.

> I've added a number of custom components to the example
> 
> ```
>     static class L extends Label {
>         public L(String s) {
>             super(s);
>             setFocusTraversable(true);
>             setMouseTransparent(false);
>         }
>     }
> ```
> 
> together with monitoring the scene's focusOwnerProperty (don't want to mess with CSS).
> 
> These "L" components do traverse with the arrow keys and your fix with and without the ScrollPane. So perhaps I am wrong and we do want this change.

Yeah, without the fix these would also need to install navigational keys in their input maps just in case someone made them focus traversable.  It's a good point that I didn't think of to justify this change, thanks for finding it.

> A couple of notes: the existing example, at least when considering its top two panels with the regular buttons, exhibits reduced accessibility when the scroll pane shows a scroll bar. One can still move focus and the scroll bar does scroll the focused component to view, but one cannot induce it to scroll (for example, if one adds a long label after the last button).

I also discovered the directional navigation seems to bug and skip controls if you reduce the spacing in the HBox's to zero, but that's a separate problem for sure.

> One can try making the scroll pane itself focusTraversable, but then the traversal becomes a bit weird. Perhaps it's a case for custom traversal policy.

I think it will be highly situational how an application would wish to handle this.  So, I'd say that a custom event handler for such keys, or perhaps indeed something with traversal policies would need to be created by the user to solve this on a case by case basis.  It will be hard to always do the expected thing with a control as generic as ScrollPane.

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

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