On Thu, 17 Jul 2025 05:56:06 GMT, Michael Strauß <mstra...@openjdk.org> wrote:
> Focus traversal is not aware of what a delegate is, nor should it be. This > means that focus traversal _will_ update the delegate chain if you traverse > into a node that hoists focus. If a key event invokes the traversal machinery it will start at the focusOwner, not one of the focusOwner's delegates. There's no way for the existing traversal machinery to tab between the sub-fields of a date/time control that is the focus owner. I've seen two methods for traversing a date/time control. In one method you use Tab to traverse to the control, through the month/day/year fields, and then beyond the control. That doesn't work well in grid-based layouts where the user expects three presses of Tab to reliably move them three columns to the right. In those designs it's not uncommon for traversal between month/day/year to move to other keys. > At the `Node` level (where controls are not a thing yet), it is more > approriate to picture focus delegation as a kind of openly visible > multi-level focus. Traversal needs to pick one node as a starting point. The Scene needs to pick one node for processing input method requests (the IM window needs to track the caret and there can only be one). I'm sure accessibility also has issues with multi-level focus but don't understand the platform API's well enough to go into any detail on that. I can see how JavaFX currently sets this up for ComboBoxes and am assuming it's correct. If it is I'm not sure the existing accessibility attributes are sufficient to convey focus beyond two levels. (We really need an accessibility guru to weigh in on this). I don't think any of these issues are necessarily deep, just that they need to be hashed out. > I'm reasonably certain that we don't need or want the delegate to be a > property. Currently you're tracking the hoisting node as an internal reference and then using it to constantly re-compute the delegate whenever you need it (going through a loop to validate the hoisting node each time). It seems you could use the hoisting node to determine the delegate while processing requestFocus and just track the delegate directly. Do you expect the delegate associated with a particular hoisting node to change over time? If not, why not just compute it once? In any case the input method state manager needs to know if the delegate chain changes. That's still a problem that needs to be solved. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1632#discussion_r2213693019
