8242489: ChoiceBox: initially toggle not sync'ed to selection #177
Conversation
|
👋 Welcome back fastegal! A progress list of the required criteria for merging this PR into |
Webrevs
|
|
@aghaisas can you review this? |
|
/reviewers 2 |
|
@kevinrushforth |
| @@ -182,6 +182,7 @@ public ChoiceBox(ObservableList<T> items) { | |||
| oldSM = sm; | |||
| if (sm != null) { | |||
| sm.selectedItemProperty().addListener(selectedItemListener); | |||
| // unfixed part of JDK-8090015 - why exclude null? | |||
There was a problem hiding this comment.
Add a TODO: or FIXME: if you intend to work on it. Also, it will be better to create a JBS issue.
If not - please remove the comment.
There was a problem hiding this comment.
Actually forgot that comment, already filed and took the issue JDK-8242001
thanks, eagle eye :)
| @@ -428,6 +412,7 @@ private void updateSelection() { | |||
| MenuItem selectedItem = popup.getItems().get(selectedIndex); | |||
| if (selectedItem instanceof RadioMenuItem) { | |||
| ((RadioMenuItem) selectedItem).setSelected(true); | |||
| } else { | |||
| toggleGroup.selectToggle(null); | |||
There was a problem hiding this comment.
The else part here means that user programmatically has selected a Separator or SeparatorMenuItem. The behavior in such scenario is not defined in doc but the methods, select(), selectNext(), selectPrevious() of ChoiceBox.ChoiceBoxSelectionModel imply that if index points to a Separator then a valid item should be selected. However these method do handle this correctly.
If these methods are implemented such that no Separator is allowed to be selected then this else part would not be needed and we might be able to remove the instanceof checks.
The fix in this PR looks good to me.
But we should also decide the behavior in above scenario and may be file a JBS.
If we decide that when a Separator is chosen for selection then the current selection should not be changed or a valid item should be selected, then the test related to Separator selection need to be changed. Or all of it can be handled in a follow on issue.
There was a problem hiding this comment.
yeah, you are right:
a) the implementation of ChoiceBoxSelectionModel is broken when it comes to handling of unselectable items (such as Separator): next/previous try to move on, the others simply select. The implementation changed in fix of JDK-8088261 - before select(index) tried to handle it, after this was moved into next/previous. Arguably, the model can do what it wants without specification ;)
b) the skin is responsible to sync the selection state of its toggles with the state of model: if the selectedIndex/Item does not have a corresponding toggle (f.i. if it's a separator), all toggles must be unselected.
c) my test related to the Separator is broken - as you correctly noted, it will fail if a future implementation decides to select a really selectable item :)
My plan:
- do nothing for a (don't feel like filing yet another bug around selection ;) and b (the skin behaves correctly, I think)
- fix the test to be resistant against implementation changes of selectionModel
Thanks for the extensive review, very much appreciated :)
There was a problem hiding this comment.
btw: just noticed that there are methods in ChoiceBoxSkin testing the fix for next/prev
@Test public void test_jdk_8988261_selectNext() {
@Test public void test_jdk_8988261_selectPrevious() {
the name look like they want to point to the corresponding issue .. but the id is incorrect: that id doesn't exist, should be 8088261 (spelling error, I think) - is it okay to change them to the right id?
There was a problem hiding this comment.
1. do nothing for a (don't feel like filing yet another bug around selection ;) and b (the skin behaves correctly, I think)
I am good with this. Though I will file a JBS for the correction in ChoiceBoxSelectionModel.
seletPrevious(), selectNext() need one more check value instanceof SeparatorMenuItem.
and similarly selectFirst() and selectLast() should be overridden correctly.
and I can't think of why select() was changed so may be rethink about it :).
We can discuss it again whenever we start fixing it.
2\. fix the test to be resistant against implementation changes of selectionModel
Thanks for link to JDK-8088261, As mentioned in this bug description, "Culprit is an incorrect override of select(int): it may reject the new index if that would select a separator, but it must not select an arbitrary index instead", So It is not sure to me what should select() do in such scenario.
So I think the test can also go as is, in case we change the behavior then test can be changed with it.
There was a problem hiding this comment.
should be 8088261 (spelling error, I think) - is it okay to change them to the right id?
That will be good to change, but not sure if as part of this bug. It will be unrelated to fix.
There was a problem hiding this comment.
At the end and following your latest comments I did nothing Except adding code comments to the separator test and the else (toggle nulling) branch.
| @@ -364,6 +343,11 @@ String getChoiceBoxSelectedText() { | |||
| return label.getText(); | |||
| } | |||
|
|
|||
| // Test only purpose | |||
| ContextMenu getChoiceBoxPopup() { | |||
There was a problem hiding this comment.
I would recommend to prefix the method name with test_. It is not followed across, only TabPaneSkin has test_ prefixed method.
There was a problem hiding this comment.
well, as TabPaneSkin is a singularity in controls (in graphics such a pattern seems to be wider-spread), I would prefer not to do it here - also because ChoiceBoxSkin has another test-only accessor (for label text) which doesn't. Might be a candidate for a general cleanup task - if we decide to really introduce such a naming convention (which I personally wouldn't like :)
- added code comments to clarify test/implemenation intention
|
@kleopatra This change now passes all automated pre-integration checks. When the change also fulfills all project specific requirements, type
Since the source branch of this PR was last updated there have been 19 commits pushed to the As you do not have Committer status in this project, an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@aghaisas, @arapte) but any other Committer may sponsor as well. ➡️ To flag this PR as ready for integration with the above commit message, type |
|
/integrate |
|
@kleopatra |
|
/sponsor |
openjdk
bot
added
integrated
|
@arapte @kleopatra The following commits have been pushed to master since your change was applied:
Your commit was automatically rebased without conflicts. Pushed as commit 69e4266. |
Macroscopic issue is that initially, the toggle is not sync'ed to the selection state. Root reason is an missing else block when updating toggle selection state (see report for details).
Fixed by introducing the else block and removing all follow-up errors that tried to amend the consequences of the incorrect selection state
The former also fixed the memory leak when replacing the selectionModel plus an unreported NPE when the selectionModel is null initially.
Added tests that failed before the fix and passed after. As there had been no tests around toggle state, so added some to verify that the change doesn't break. Enhanced shim/skin to allow access to popup for testing. Removed the informally ignored test part for memory leak.
Progress
Issue
Reviewers
Download
$ git fetch https://git.openjdk.java.net/jfx pull/177/head:pull/177$ git checkout pull/177