On Mon, 14 Jul 2025 18:36:48 GMT, Martin Fox <m...@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
