On Fri, 16 Oct 2026 20:15:35 GMT, Marius Hanl <[email protected]> wrote:
>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java >> line 2883: >> >>> 2881: } >>> 2882: >>> 2883: return getScene().getFocusOwner().getScene() != null; >> >> a listener might have moved the cell graphics to another scene. this method >> will return `true` causing the new code to skip the focus recovery. > > 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 ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2347#discussion_r4299291376
