On Tue, 14 Jul 2026 21:59:46 GMT, Andy Goryachev <[email protected]> wrote:
> I wonder if there are more edge cases like the one you just fixed, but it is > very difficult to analyze. You did find some very nice edge cases, on top of many issues that were already fixed over a year ago. They were subtle enough that normal JavaFX applications that were tested never even ran into them (nor did any of the pre-existing and new test code, including all our integration tests that spin up partial FX applications -- listeners are everywhere...) We can't prove it is bug free, but if we can add it early in the next cycle, there should be sufficient time to test it against large real world apps and see if anything was missed. > From the application perspective, it is probably a bad idea to rely on > (deeply) nested event handling anyway. Let's see what other reviewers find > out. Agreed. It can happen unnoticed though easier than you'd think. Some actions if taken by a listener can have huge consequences. Modifying the scene graph (add/remove nodes) or changing the scene root can have deep stack traces. There are also a few places in FX where properties are changed on a critical path, not realizing that some user code may trigger on a harmless looking "set" call, as they might be listening on such a property (especially uncommon properties like (layout) bounds). These can then trigger a re-entrant change depending on what they do in turn. In some of my own projects, I make use of special properties that can "delay" notifications until we're off the critical path, so there is no chance of some user listener code interfering. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-4974543469
