On Wed, 3 Jun 2026 17:29:55 GMT, Marius Hanl <[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). > > Can we instead do something like this in `ComboBoxListViewSkin`: > > > ... > lh.addChangeListener(control.converterProperty(), e -> { > listView.refresh(); > buttonCell.updateIndex(-1); // <--- NEW > updateDisplayNode(); > }); > ... > > > This makes more sense to me. I understand the problem and your reasoning. > If the converter changes, we want to refresh the `ListView`. But we should > also force the `buttonCell` to refresh, hence we should reset to -1. > > Then you can revert `updateDisplayNode` to not call > `buttonCell.updateIndex(-1);`. All tests still pass for me and the fix makes > more sense - in this case the `buttonCell` is 100% stale and we need to > consider that. @Maran23 I updated the test case to show that setting the prompt text is also affected. It now runs multiple methods that all call updateDisplayNode() in some way, which breaks in the same way ------------- PR Comment: https://git.openjdk.org/jfx/pull/2179#issuecomment-4633250365
