On Mon, 1 Jun 2026 01:43:45 GMT, Christopher Schnick <[email protected]> wrote:
> This is a much simpler fix for JDK-8384806 which does not have any side > effects. > > This restores the old code with only a one line change instead. For > reference, see > https://github.com/openjdk/jfx/commit/8d917ae738120e12ac12cd0957879b7c00e59b03. > We now fix the issue by clearing the cell with `buttonCell.updateIndex(-1);` > as using `buttonCell.setItem(null);` was causing the original issue when the > item was already null. > > --------- > - [x] I confirm that I make this contribution in accordance with the [OpenJDK > Interim AI Policy](https://openjdk.org/legal/ai). I'm also wondering in what usecase this is broken. Background: Setting the index to a `Cell`, even if it is the very same index will trigger the `indexChanged` code. In there, we will check if the item is the same as before and not call `updateItem` then. Resetting the index to `-1` and then back to the original index is therefore only needed when something changed that the `Cell` can not observe and we really want kind of forcefully call `updateItem`. This is done in `VirtualFlow` (reset index, set again), because a row might not change but a cell in the row could. Example: We change the name of a `Person`. The `Person` object is the same, but the name is not (new `String`). But in `ListCell`, things are easier, so I just wonder if there is a case we really need this (then this PR is the correct approach) or something else is off. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2179#issuecomment-4595572091
