On Thu, 12 Mar 2026 18:38:37 GMT, Marius Hanl <[email protected]> wrote:
>> This is an implementation for the long standing issue of allowing to commit >> a cell value when the focus is lost or the editing index (cell) changed. >> This also contains >> [JDK-8089311](https://bugs.openjdk.org/browse/JDK-8089311) (for better >> understanding the usecase with `TextField` cells, but we may split this >> later on). >> >> API >> - >> - Instead of calling `cancelEdit`, every cell now calls `stopEdit` 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 `commitEdit` instead >> - There are multiple 'events' that can lead to a editing change. Every >> change will now call `stopEdit`. >> 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. Therefore, we do not always know what >> intention led to a change of the editing index. >> - Every `MOUSE_PRESSED` shifts the focus to the cell container, which is >> undesired in case of editing the cell. So this event is now consumed. The >> cell container will request focus before (if it is not yet set) >> Note: So basically, we request focus a tiny bit earlier (for commit reasons) >> instead of after, which interruppts the commit >> - All `TextField` cells now commit their value (instead of cancel) on focus >> loss >> - `TextField` Escape handling was badly implemented (it was never really >> called, as the cell container handled Escape before) >> >> Considerations >> - >> - I tried to make the API minimal, and without breaking changes (other than >> the `TextField` cells committing their values, but we may split this up) >> - Clicking the `ScrollBar` 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 (`focusWithin`) >> - It might be hard for a developer to exactly know the cause why `stopEdit` >> is called. This does not seem like a problem, as e.g. for a `TextField`, you >> normally register listeners for e.g. focus loss for commit or pressing the >> Escape key for cancel, so you keep full control. >> >> Possible next PRs >> - >> - 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 `focusWithin` property instead for all 4 C... > > Marius Hanl has updated the pull request incrementally with one additional > commit since the last revision: > > make it final, improve docs Note: We could also close the issues that are very closely related. I decided to first add all issues here that I can confirm are fixed by this PR, so we do not have any stale issues later on and I feel like we can manage this better in one place (here). But fine with whatever we agree on (Either way, it's a bit clearer now what issues are affected). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1935#issuecomment-4106441779
