<div style="font-family: 'verdana'; font-size: 12px; color: #000;"><span style="background-color: #ffffff;">All,</span></div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;"><span style="background-color: #ffffff;"> </span></div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;"><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 style="font-family: 'verdana'; font-size: 12px; color: #000;"><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 style="font-family: 'verdana'; font-size: 12px; color: #000;">All information mentioned here are also in the description of the PR.</div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;"> </div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;"><strong>API</strong></div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;"><strong> </strong></div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;"><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 style="font-family: 'verdana'; font-size: 12px; color: #000;"><span style="background-color: #ffffff;"> </span></div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;"><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 style="font-family: 'verdana'; font-size: 12px; color: #000;"><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 style="font-family: 'verdana'; font-size: 12px; color: #000;"><span style="background-color: #ffffff;"> </span></div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;"><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.<br></span></div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;"><span style="background-color: #ffffff;"> </span></div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;"><span style="background-color: #ffffff;">1* - <a href="https://github.com/openjdk/jfx/pull/1935" target="_blank" rel="noopener noreferrer">https://github.com/openjdk/jfx/pull/1935</a></span></div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;"><span style="background-color: #ffffff;">2* - <a href="https://bugs.openjdk.org/browse/JDK-8089514" target="_blank" rel="noopener noreferrer">https://bugs.openjdk.org/browse/JDK-8089514</a></span></div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;"><span style="background-color: #ffffff;">3* - <a href="https://bugs.openjdk.org/browse/JDK-8089311" target="_blank" rel="noopener noreferrer">https://bugs.openjdk.org/browse/JDK-8089311</a></span></div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;"><span style="background-color: #ffffff;"> </span></div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;"><span style="background-color: #ffffff;">-- Marius</span></div>