RFR: 8343956: Focus delegation API [v3]

Michael Strauß mstrauss at openjdk.org
Thu Jul 17 06:32:55 UTC 2025


On Mon, 14 Jul 2025 18:36:48 GMT, Martin Fox <mfox at openjdk.org> wrote:

> In this PR setting hoistFocus on a control only updates the flag in the control itself. What if the control’s skin introduces sub-nodes? I would assume that setting hoistFocus on a control would automatically set that flag on the control’s entire skin. Is that correct? If so what are the mechanics of making that happen?

The `hoistFocus` flag only applies to the node on which it is set, and not to its descendants. Consider a control that uses a sub-control in its skin. If the sub-control also delegates focus to one of its own descendants, then those descendants individually get to decide whether to hoist focus to the sub-control; and if so, the sub-control will further hoist focus to the outer control.

Automatically setting this flag precludes the option to have sub-nodes that _don't_ hoist focus. Consider a Button: it has an optional sub-node (`graphic`) that is independently focusable and doesn't hoist focus. A custom button could conceivably have both: a delegate (maybe a text field), as well as an independently focusable sub-node.

> It seems hoistFocus is serving two roles. One is an optimization so that requestFocus knows whether it should walk the scene graph looking for a focus-scope node. For that use the flag should be propagated through descendants in the graph. But it’s also being proposed as a hoisting barrier e.g. when it’s _not_ set it prevents focus from hoisting upward even if there's a focus-scope node higher up in the graph. But a barrier applies just to a single node and should not be propagated. So I’m having a difficult time figuring out when and how this flag should be propagated through the tree. But I’m no expert on skins so maybe I’m assuming this is more complicated than it actually is.

`hoistFocus` is not an optimization, it's semantically relevant in the way I described.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1632#discussion_r2212398078


More information about the openjfx-dev mailing list