<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Marius,<br>
<br>
Focus lost is currently sort of a proxy of starting an interaction
with a new control, but not all controls gain focus when
interacted with. Buttons are one of those (either with mouse
press or keyboard short cut), but there is I think also the scroll
wheel that can interact with a control without focusing it (and
perhaps even popup menu's).<br>
<br>
I can only think of one half-baked solution to this:</p>
<p>- Have a new Event type that is always targetted at the current
focus owner ("InterestLostEvent" ? :))<br>
- This event is automatically fired by Scene just before an event
is fired that is not targetted at the current focus owner, AND the
last event fired did have the focus owner as target</p>
<p>What would happen in practice then would be something like:</p>
<p>- User edits field, keypress events go to current focus owner<br>
- User does something else (moves mouse, scrolls, presses a
hotkey, or presses a button):<br>
- An InterestLostEvent is fired at the current focus owner
BEFORE the new event is fired<br>
- The delayed new event is now fired<br>
- No further InterestLostEvents are fired until the focus
owner has received a normal event again<br>
- User goes back to editing after playing with the mouse; events
targetted at the focus owner renew the interest in that control,
and so next time an InterestLostEvent is fired again when needed<br>
</p>
<p>It feels a bit awkward, especially because simple things like
mouse moves may trigger it already (but a mouse move may trigger
something that requires the model to be up to date...); perhaps it
would need to be selective in some way so one can choose to only
be interested in the InterestLostEvent on focus loss and mouse
clicks.<br>
<br>
I can immediately see some problems as well. Some controls I
think allow editing without focus gain/loss at all (I think some
controls can be edited by just scrolling the mouse wheel over
them). When should those controls "commit" their values...?<br>
</p>
<p>--John<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 15/10/2025 16:39, Marius Hanl wrote:<br>
</div>
<blockquote type="cite"
cite="mid:trinity-faddf223-0462-4cd6-8321-a9f7e02814fb-1760539166281@trinity-msg-rest-webde-webde-live-f747bc64b-4q5f4">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div style="font-family: 'verdana'; font-size: 12px; color: #000;">Hi
John,</div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;"> </div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;">you
are right that there might be corner cases. I hope that
we could, what Andy suggests, find all cases and have a deeper
look at them.</div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;">We
can also check whether the focus delegation API from Michael is
something that could help us here (but might be completely
unrelated).</div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;"> </div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;">The
other options as you also mentioned, also have their problems.
Even debouncing a commit on every keystroke can be unreliable if
the user is too fast.</div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;">I
really hope we can make the focus loss reliable, as we then do
not need much of an API changes inside the Cell Framework.</div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;"> </div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;">--
Marius</div>
<div id="sub-body-container"
style="margin: 10px 5px 5px 10px; padding: 10px 0px 10px 10px; border-left: 2px solid rgb(195, 217, 229);">
<div style="margin: 0px 0px 10px;">
<div><strong>Gesendet: </strong>Montag, 13. Oktober 2025 um
19:32</div>
<div><strong>Von: </strong>"Andy Goryachev"
<a class="moz-txt-link-rfc2396E" href="mailto:andy.goryachev@oracle.com"><andy.goryachev@oracle.com></a></div>
<div><strong>An: </strong>"John Hendrikx"
<a class="moz-txt-link-rfc2396E" href="mailto:john.hendrikx@gmail.com"><john.hendrikx@gmail.com></a>, <a class="moz-txt-link-rfc2396E" href="mailto:openjfx-dev@openjdk.org">"openjfx-dev@openjdk.org"</a>
<a class="moz-txt-link-rfc2396E" href="mailto:openjfx-dev@openjdk.org"><openjfx-dev@openjdk.org></a></div>
<div><strong>Betreff: </strong>Re: Allowing a cell to commit
the value on focus loss</div>
</div>
<div
style="font-family: 'Iosevka Fixed SS16' , Arial , Helvetica , sans-serif; font-size: 12.0pt; color: #000000;">I
wonder if we should find out exactly why onFocusLost does not
work in these cases, as expected. Then, if I understand the
proposal correctly, we won't need any API changes.</div>
<div
style="font-family: 'Iosevka Fixed SS16' , Arial , Helvetica , sans-serif; font-size: 12.0pt; color: #000000;"> </div>
<div
style="font-family: 'Iosevka Fixed SS16' , Arial , Helvetica , sans-serif; font-size: 12.0pt; color: #000000;">-andy</div>
<div
style="font-family: 'Iosevka Fixed SS16' , Arial , Helvetica , sans-serif; font-size: 12.0pt; color: #000000;"> </div>
<div
style="font-family: 'Iosevka Fixed SS16' , Arial , Helvetica , sans-serif; font-size: 12.0pt; color: #000000;"> </div>
<div id="mail-editor-reference-message-container">
<div class="ms-outlook-mobile-reference-message skipProofing"> </div>
<div class="ms-outlook-mobile-reference-message skipProofing"
style="text-align: left; padding: 3.0pt 0.0in 0.0in; border-width: 1.0pt medium medium; border-style: solid none none; font-family: Aptos; font-size: 12.0pt; color: black;"><strong>From:
</strong>openjfx-dev <a class="moz-txt-link-rfc2396E" href="mailto:openjfx-dev-retn@openjdk.org"><openjfx-dev-retn@openjdk.org></a> on
behalf of John Hendrikx <a class="moz-txt-link-rfc2396E" href="mailto:john.hendrikx@gmail.com"><john.hendrikx@gmail.com></a><br>
<strong>Date: </strong>Monday, October 13, 2025 at 07:17<br>
<strong>To: </strong><a class="moz-txt-link-abbreviated" href="mailto:openjfx-dev@openjdk.org">openjfx-dev@openjdk.org</a>
<a class="moz-txt-link-rfc2396E" href="mailto:openjfx-dev@openjdk.org"><openjfx-dev@openjdk.org></a><br>
<strong>Subject: </strong>Re: Allowing a cell to commit the
value on focus loss<br>
<br>
</div>
<p class="ms-outlook-mobile-reference-message skipProofing">Hi
Marius,</p>
<p class="ms-outlook-mobile-reference-message skipProofing">This
may be unrelated, but it may be problematic to rely on
committing values using focus lost:</p>
<p class="ms-outlook-mobile-reference-message skipProofing">I've
built a lot of code that relies on focus lost to "commit"
values to some underlying model. However, I noticed that a
focus lost handler for committing values is insufficient
when an action is triggered that doesn't trigger a loss of
focus. For example, if I have a field "email address" and
a Button "Send Email", and I have a focus lost handler to
commit the email address textfield to an underlying model,
then pressing the Button will not trigger that handler and
the underlying model may not have been updated with the
latest edits.</p>
<p class="ms-outlook-mobile-reference-message skipProofing">Solutions
to trigger the correct action are all a bit tricky or
annoying:</p>
<p class="ms-outlook-mobile-reference-message skipProofing">-
Query all fields for their current contents as focus lost is
not entirely reliable for this purpose<br>
- Have fields update models immediately (which would be on
every key press...) -- this is not very efficient, and can
get in the way of validation / model restrictions<br>
- Have controls listen to a "COMMIT" event (this is fired at
the current focus owner by the Button). This event may be
veto'd if committing the value resulted in a validation
error, in which case the button press is cancelled</p>
<p class="ms-outlook-mobile-reference-message skipProofing">I
don't like any of these, but using the last option at the
moment because I like constant updates and having to requery
UI components even less...</p>
<p class="ms-outlook-mobile-reference-message skipProofing">--John</p>
<p class="ms-outlook-mobile-reference-message skipProofing"><br>
I noticed however that if you edit some field (it doesn't
have to be in a table view, just a regular field), and have
a focus lost handler that commits the value, that this focus
lost handler is insufficient...</p>
<div class="moz-cite-prefix">On 13/10/2025 14:53, <a
class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:mariushanl@web.de" target="_blank"
rel="noopener noreferrer" moz-do-not-send="true">
mariushanl@web.de</a> wrote:</div>
<blockquote>
<div
class="ms-outlook-mobile-reference-message skipProofing"
style="font-family: verdana; font-size: 12.0px; color: #000000;"><span
style="background-color: #ffffff;">All,</span></div>
<div
class="ms-outlook-mobile-reference-message skipProofing"
style="font-family: verdana; font-size: 12.0px; color: #000000;"><span
style="background-color: #ffffff;"> </span></div>
<div
class="ms-outlook-mobile-reference-message skipProofing"
style="font-family: verdana; font-size: 12.0px; color: #000000;"><span
style="background-color: #ffffff;">I created an initial
poc 1* to support developers to commit the cell value
when the focus is lost 2* (including 3*).</span></div>
<div
class="ms-outlook-mobile-reference-message skipProofing"
style="font-family: verdana; font-size: 12.0px; color: #000000;"><span
style="background-color: #ffffff;">More specifically,
this gives the maximum flexibility to choose what should
happen when the focus is lost or the editing index
changed (which may happen when clicking into another
cell while editing).</span></div>
<div
class="ms-outlook-mobile-reference-message skipProofing"
style="font-family: verdana; font-size: 12.0px; color: #000000;">All
information mentioned here are also in the description of
the PR.</div>
<div
class="ms-outlook-mobile-reference-message skipProofing"
style="font-family: verdana; font-size: 12.0px; color: #000000;"> </div>
<div
class="ms-outlook-mobile-reference-message skipProofing"
style="font-family: verdana; font-size: 12.0px; color: #000000;"><strong>API</strong></div>
<div
class="ms-outlook-mobile-reference-message skipProofing"
style="font-family: verdana; font-size: 12.0px; color: #000000;"><strong> </strong></div>
<div
class="ms-outlook-mobile-reference-message skipProofing"
style="font-family: verdana; font-size: 12.0px; color: #000000;"><span
style="background-color: #ffffff;">- Instead of calling
`<em>cancelEdit</em>`, every cell now calls `<em>stopEdit</em>`
when the focus is lost or the editing index changed. The
default behavior is cancelling the edit, but developers
can now override the behavior and allow a `<em>commitEdit</em>`
instead<br>
- There are multiple 'events' that can lead to a editing
change. Every change will now call `<em>stopEdit</em>`.<br>
It is therefore the responsibility of the developer to
decide, when it makes sense to actually commit the value
instead of cancelling it. This decision was made as the
behavior is manipulating the editing index, but you as a
developer can as well. We do not really know what
intention led to e.g. a change of the editing index.<br>
- Every `<em>MOUSE_PRESSED</em>` shifts the focus to the
cell container, which is undesired in case of editing
the cell. So this event is now consumed.<br>
- All `<em>TextField</em>` cells now commit their value
(instead of cancel) on focus loss<br>
- `<em>TextField</em>` Escape handling was badly
implemented (it was never really called, as the cell
container handled Escape before)</span></div>
<div
class="ms-outlook-mobile-reference-message skipProofing"
style="font-family: verdana; font-size: 12.0px; color: #000000;"><span
style="background-color: #ffffff;"> </span></div>
<div
class="ms-outlook-mobile-reference-message skipProofing"
style="font-family: verdana; font-size: 12.0px; color: #000000;"><span
style="background-color: #ffffff;"><strong>Considerations</strong><br>
<br>
- I tried to make the API minimal, and without breaking
changes (other than the `<em>TextField</em>` cells
committing their values, but we may split this up)<br>
- The Cell Container focus behavior is, well, weird
right now. That is why consuming the event is needed to
better support this PR. One thing we may can consider is
using the `<em>focusWithin</em>` property instead for
all 4 Cell Containers and not calling `<em>requestFocus</em>`
for nearly every `<em>MOUSE_PRESSED</em>` event. If we
decide so, this is needs to be done before merging this
PR.<br>
- Clicking the `<em>ScrollBar</em>` now commits/cancels
the edit. I checked other applications and this is very
common. But something I need to note here. This probably
can be fixed in the same way mentioned above (`<em>focusWithin</em>`)</span></div>
<div
class="ms-outlook-mobile-reference-message skipProofing"
style="font-family: verdana; font-size: 12.0px; color: #000000;"><span
style="background-color: #ffffff;">- It might be hard
for a developer to exactly know the cause why `<em>stopEdit</em>`
is called. This does not seem like a problem, as e.g.
for a `<em>TextField</em>`, you normally register
listeners for e.g. pressing the Escape key on it, so you
keep full control.</span></div>
<div
class="ms-outlook-mobile-reference-message skipProofing"
style="font-family: verdana; font-size: 12.0px; color: #000000;"><span
style="background-color: #ffffff;"> </span></div>
<div
class="ms-outlook-mobile-reference-message skipProofing"
style="font-family: verdana; font-size: 12.0px; color: #000000;"><span
style="background-color: #ffffff;"><strong>Another
Approach</strong><br>
<br>
- Another Approach I tested could be to request the
focus to a cell when clicked/edited, to ensure that the
focus listener is ALWAYS called before another cell will
reach the editing state. Again, we probably need to
change the focus handling to e.g. use the `<em>focusWithin</em>`
property. With this approach, we can only call `<em>stopEdit`
</em>when the focus changed (since it is now called
always), but not when the editing index changed.</span></div>
<div
class="ms-outlook-mobile-reference-message skipProofing"
style="font-family: verdana; font-size: 12.0px; color: #000000;"><span
style="background-color: #ffffff;"> </span></div>
<div
class="ms-outlook-mobile-reference-message skipProofing"
style="font-family: verdana; font-size: 12.0px; color: #000000;"><span
style="background-color: #ffffff;">1* - <a
class="moz-txt-link-freetext"
href="https://github.com/openjdk/jfx/pull/1935"
target="_blank" rel="noopener noreferrer"
moz-do-not-send="true">
https://github.com/openjdk/jfx/pull/1935</a></span></div>
<div
class="ms-outlook-mobile-reference-message skipProofing"
style="font-family: verdana; font-size: 12.0px; color: #000000;"><span
style="background-color: #ffffff;">2* - <a
class="moz-txt-link-freetext"
href="https://bugs.openjdk.org/browse/JDK-8089514"
target="_blank" rel="noopener noreferrer"
moz-do-not-send="true">
https://bugs.openjdk.org/browse/JDK-8089514</a></span></div>
<div
class="ms-outlook-mobile-reference-message skipProofing"
style="font-family: verdana; font-size: 12.0px; color: #000000;"><span
style="background-color: #ffffff;">3* - <a
class="moz-txt-link-freetext"
href="https://bugs.openjdk.org/browse/JDK-8089311"
target="_blank" rel="noopener noreferrer"
moz-do-not-send="true">
https://bugs.openjdk.org/browse/JDK-8089311</a></span></div>
<div
class="ms-outlook-mobile-reference-message skipProofing"
style="font-family: verdana; font-size: 12.0px; color: #000000;"><span
style="background-color: #ffffff;"> </span></div>
<div
class="ms-outlook-mobile-reference-message skipProofing"
style="font-family: verdana; font-size: 12.0px; color: #000000;"><span
style="background-color: #ffffff;">-- Marius</span></div>
</blockquote>
</div>
</div>
</blockquote>
</body>
</html>