On Tue, 24 Mar 2026 16:06:51 GMT, Andy Goryachev <[email protected]> wrote:
> Would it be possible to expand the PR description to illustrate a couple of > examples wrt changes in behavior and also the kind of changes the application > need to make to adapt to the new behavior? Sure. But to be honest, I don't know what developers need to adjust. It's hard to say what existing apps have done so far to fix this issue - or whether they've simply taught their users to always press the Enter key. đŸ˜€ Since this change has no impact on existing cells, it’s not a problem. It only affects subclassed `TextFieldXXXCell`s. I don’t think developers have done that very often. Since you can’t access the `TextField`, but you need it to implement the commit when focus is lost behavior. That’s exactly what I did. A custom cell implementation with a `TextField`, a bunch of listeners, and an attempt to guess when `cancelEdit` is called even though a commit should happen instead—and then triggering a `commitEdit` instead. > One question I must ask is whether it's possible / worth it to hide the new > behavior behind a system property, for people who spent a lot of time making > their apps work with the existing behavior and who are reluctant / unable to > spend more time fixing it again? This would only help for the case described above - If developers subclasses `TextFieldXXXCell`s. We could do that here, sure, and I don't have a problem with that at all! But I don't think this was done often, if at all. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1935#issuecomment-4120756715
