On Tue, 18 Aug 2026 20:28:43 GMT, Andy Goryachev <[email protected]> wrote:
>> modules/javafx.controls/src/main/java/javafx/scene/control/Cell.java line
>> 359:
>>
>>> 357: * would have focused set to true.
>>> 358: */
>>> 359: focusedProperty().addListener(_ -> {
>>
>> I realize this is old behavior but using the focused property is
>> questionable. The focused property will be set to false if the user
>> activates a different window. In most toolkits clicking on a different
>> window would not commit text entry. The text should just sit there waiting
>> for the user to re-activate the original window.
>>
>> The more correct way of doing this is to observe the scene's focusOwner
>> since that doesn't change when the window loses focus. But it's possible
>> you're picking up other behavior by monitoring the focused property that's
>> important, I know the controls mess with it in various ways.
>
>> The text should just sit there waiting for the user to re-activate the
>> original window.
>
> this behavior might depend on the application requirements, so perhaps it
> needs to be configurable?
This just follows the same behavior as `DatePicker`, `ComboBox`, `Spinner`.
However, I do think we could improve that handling in a follow up.
I have this year for more than a year already:
Instead of registering a focus listener, we should rather have a protected
`focusChanged` method.
Two advantages:
- Developers can finally completely override that behavior
- Less listeners
With the `focusOwner` idea, we may have a third advantage / usecase:
Since focus is a concept on the scene, we also could call this method on focus
owner change instead.
And I think this can be a toggle on the `Scene` and is actually possible to
implement with full backward-compatibility. I think.
Something I would explore after this PR. It is not a blocker IMO.
-------------
PR Review Comment: https://git.openjdk.org/jfx/pull/1935#discussion_r3934071351
