On Fri, 16 Oct 2026 20:59:15 GMT, Andy Goryachev <[email protected]> wrote:
>> This seems to be another case where your 'buddy' did probably tell you that. >> Such extreme hypothetical problems do not help to find a good fix. I can >> also ask a buddy myself, but I'm not interested -- I'm interested in other >> opinions and real thoughts into this problem. >> >> We could also add a `visibleProperty` listener, or a `parentProperty` >> listener and shift the focus again and will steal the focus. The previous >> solution broke for all the scenarios while scanning the whole scene tree. >> This solution will at least not steal anything. >> >> As always with properties in JavaFX, we can not rely on any state. Listeners >> can re-modify it, breaking all our assumptions. >> It is the same in CSS, which as you know has a fair share of rleated >> problems. >> >> We can at this point only factor in the happy path and some strange paths, >> but not the super weird hyper hypothetical user may do the weirdest things >> ever scenarios. > > I agree with you on all points! > > I am not sure why the original developers decided that cells are precious and > need to be cached and reused. Maybe because the Node is heavy with all these > properties, I don't know. Perhaps, with gigabytes of RAM, we don't even > care. The cells should not be reused, much like popups and menus. > > The question is whether this is a legitimate enough case (like the previous > one), and I guess you are saying it is not (and I agree). > > lgtm Thanks for your understanding! The property (listener) system in JavaFX really has this downside: you can’t rely on any state. Developers can simply add a listener and revert the state, change something else, or even modify the whole scene structure! So it’s very hard to find the right balance. Most of the time you won’t notice (it just works), but as soon as a case gets a bit more complex or unusual, like this one or CSS, you end up playing whack-a-mole with edge cases: trying to think of every possible shenanigan a developer could do, and then fixing, avoiding, or detecting it. This is super hard to get right, and even worse: There is no perfect solution. For `VirtualFlow`, we have another super weird case here: https://github.com/openjdk/jfx/blob/cb56d4c90fe7a43079688b92c54c7d2b364c7232/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java#L475-L500 Both (this and the linked) case are not called in my testing anyway, so probably again from the 2011 closed source we will never know era. And in the table, we also play the game of 'developer may changed focus, maybe not, lets try to find out with walking the scene tree': https://github.com/openjdk/jfx/blob/cb56d4c90fe7a43079688b92c54c7d2b364c7232/modules/javafx.controls/src/main/java/javafx/scene/control/TableCell.java#L358-L366 Thats also why https://github.com/openjdk/jfx/pull/1081 is a good step. But the problem remains: I can not trust any state, developers may override it in a listener. This is one of the biggest problems in JavaFX without a good solution. Or to say it in other words: If we could process the layout and css without the developer potentially interfering, and we notify the listeners after we are done, we won't have any of the current problems, not in CSS, not this discussion. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2347#discussion_r4313207013
