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. > But we don’t do that for mouse events. When clicking on a ComboBox (or Button > or whatever) the event’s target is set to whatever object the user clicked on > even if it’s an undocumented piece in the control’s skin. I would like to see > a discussion on why we’re trying to hide the use of composition here when we > don’t elsewhere. It has always been this way, and the delegation API does not change this. It only makes it easier to forward these events automatically to a delegate. However, you do touch on an interesting point. I think Controls and their Skins should enforce their black box for mouse events as well. As Control does provide several interesting encapsulations already (it makes Skin styleable properties part of its own styleable properties for example) it perhaps should have done this from the beginning, so that a MouseEvent when intercepted by users will show a click on a Spinner, and not "internal_arrow_region_2" or whatever. The forwarded events will be only visible to the Skin internals, and can't be intercepted by users, and so they would never see internals. Note that they can already do so by setting `pickOnBounds` to `true` for the Control (control can override this property to be always true), and forcing all children to be mouse transparent (control can monitor children and force them to be transparent) -- it perhaps should have been enforced to be this way from the beginning. All that would be needed then is to forward the event still to the correct internal target. --John
