On Thu, 17 Jul 2025 05:18:28 GMT, Michael Strauß <[email protected]> wrote:
>> Implementation of [focus >> delegation](https://gist.github.com/mstr2/44d94f0bd5b5c030e26a47103063aa29). > > Michael Strauß has updated the pull request incrementally with one additional > commit since the last revision: > > Avoid variable reassignment @maran23 I’ve never paid much attention to the Node focused property since it doesn’t play any role in the delivery of key events. It would be really helpful if you could give a brief summary of what it does and, more importantly, how it’s used. Based on your notes it looks like text input controls consult this property to determine when to show their carets. In the context of this PR this means that the “focused” property needs to be set on the focus owner’s delegate (the TextField) rather than the focus owner (the Spinner or ComboBox) as the spec currently reads. This is just another part of the system that needs to be shifted from the focus owner to the delegate. We also need to use the delegate as the target for Key and InputMethod events and ensure it’s consulted for input method requests. (I do wonder if it would make more sense for Spinner and ComboBox to set the focus owner to the TextField instead. This seems to be how the system was designed to function. The focused property would work as expected, the pseudo-classes would work as expected, events would automatically be targeted at the right control, input method requests would work. Even the accessibility API seems to be designed for this; the FOCUS_ITEM accessibility property makes it easy to retrieve the Spinner or ComboBox from the TextField.) It also looks like container controls like TableView are setting the “focused” property on their cells. Why? To add the “focus” pseudo-class to the cell so it displays a focus ring? Whatever TableView is doing with “focused” what’s your proposed replacement? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1632#issuecomment-4164876405
