> On Aug 5, 2025, at 4:07 PM, John Hendrikx <john.hendr...@gmail.com> wrote: > > > On 05/08/2025 22:01, Martin Fox wrote: >> I have some questions related to the spec. I think some of this has been >> addressed in the PR but not in the documentation. >> >> - This spec goes through some trouble to ensure that the target of a >> KeyEvent is the ComboBox/Spinner and not its TextField. > > This is not new in this spec though. KeyEvents are delivered to the > focused control. The focused node has always been the Control, and not > any part of its Skin.
The TextField of a ComboBox or Spinner is not just an artifact of its skin. They are both explicitly composite controls that contains a TextField inside. It’s part of the API. And if you were to install some filters on the Scene to track Key and InputMethod events you could easily conclude that that TextField is the focus owner (it walks like the focus owner, it quacks like the focus owner). I believe the implementation of Spinner predates focusWithin and focusVisible. I think the natural way to drive the focus indicators these days would be to use focused for the TextEdit and focus-within for the Spinner. In any case I think it’s a good idea to somehow separate these out and not force all of these flags to be set in unison across the entire delegate chain. If we were to make the Spinner’s TextEdit the focus owner input methods would work, the focused and focus-within pseudo-classes would sort themselves out in a natural way, and the double firing of KeyEvents would go away. The downside is that you would create an information deficit during event processing; the event target would be the TextEdit and not the logical control. But that’s an existing problem that also affects mouse click events. Perhaps we should focus on closing that information gap instead. Martin
