On Wed, 20 May 2026 15:42:14 GMT, Michael Strauß <[email protected]> wrote:
> This depends on the definition of "failure mode". With this solution, an > event listener that is installed on a node in the skin subgraph that > eventually contains the `TextField` will not see the event (because it does > not travel through the subgraph, it is dispatched directly to the final > target). This is different from how events in the scene graph usually work. I thought about this but only in the context of the default skin (I doubt we want to encourage clients to attach event listeners to random parts of the skin we create). I forgot that clients can create their own skins and may want to attach filters and handlers. I could alter the code so the dispatch chain covers the entire skin. Just to be clear I don't like the solution in this PR. I began prototyping some cleaner approaches but was stymied by the control/skin/behavior split which is particularly murky with ComboBox and Spinner. These skins are also playing games with the way they handle ENTER and ESCAPE which would also need to be re-worked. Here's a question: if you install a KeyEvent filter on a scene and the user is typing in a ComboBox would you prefer the target of the key event to be the ComboBox or the TextField? In the master branch you would see two events, one targeted at the ComboBox and the other at the TextField. If you had to choose just one which would it be? This is a general question about how key event forwarding should work. If the answer is ComboBox then this crude solution will be enough until something better comes along. If the answer is TextField then we should probably scrap this PR rather than set a bad precedent. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2166#issuecomment-4501095553
