8209788: Left/Right/Ctrl+A keys not working in editor of ComboBox if popup showing #172
Conversation
|
Webrevs
|
/reviewers 2 |
@kevinrushforth |
Hi @arapte, Great work on the PR Don't you think that all the changes in Moreover, |
good point :) Though - I don't like listeners to control properties in behaviors, and much less listeners to path properties (they tend to not getting cleaned on dispose). In the particular case of behaviors of controls with selectionModels they do (must?) because the selectionModel is not api complete (having no notion of anchor), so they jump in to cover up. Hopefully that design flaw will be fixed at some time in future, which would remove the existing listener, anyway. With just another responsibility - difference based on selectionMode - such cleanup would be harder. Here the basic approach is to add/remove a keyMapping for multiple/single selection. Compared to current state, there's a subtle side-effect (the event bubbles up if the mapping if removed). We can achieve the same behavior (with the same side-effect) by making the mapping consume depending on whether it is handled (to select all) or not. In code that would be pattern like:
BTW, there are other keys that don't work as expected (from the perspective of the editor in the combo): f.i. shift-home/end is mapped to scrollToFirst/LastRow - that's hampering ux if f.i. the user has typed some input, uses them and sees her input lost because first/last row is selected. Sry to not have noticed earlier in my bug report :( So whatever approach we choose (mappings being removed/added or their handlers not/consuming doesn't matter), we would have to do it for several keys. Plus we have the side-effect mentioned above. The mass of change for all listviews has a certain risk of breaking existing code. Think f.i. global accelerators that might (or not) get triggered depending on selection mode. On the other hand, different mappings are needed only when the list resides in the combo's popup (and probably only if the combo is editable, didn't dig though). An alternative might be a different inputMap (or containing different mappings) when used in combo's popup (which is similar to what Swing/X does .. no wonder I would prefer it :) |
Hi @abhinayagarwal, Thanks for the suggestion. This sound good to me too. I shall make this change in next commit. |
Changing the behavior inside
It's sad that we can't easily override (InputMapping created in) |
Thanks for the suggestion |
the nearest to different input maps based on control state might be in listViewBehavior itself: it has differrent child maps for vertical/horizontal orientation. Could be possible to widen that a bit with another child map for vertical and in combo popup (provided it has a means to decide being in such a state for the sake of an interceptor, without api change that might be a simple entry in its properties) |
@arapte this pull request can not be integrated into git checkout ComboBox_Editor
git fetch https://git.openjdk.java.net/jfx master
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge master"
git push |
Once the merge conflicts and review comments are addressed, I'll put this back on my review queue. |
Please review the updated change:
Change is very specific to ComboBox editor, so it should not affect any other tests. |
...avafx.controls/src/main/java/javafx/scene/control/skin/ListViewSkin.java
Outdated
Show resolved
Hide resolved
fix and tests look okay (added minor inline comments), verified that the tests for the fix are failing before and passing after, those added for completeness are fine also. As noted in one of my comments (again? :), I don't like underscores .. not even in test methods - but as they are wide spread nothing to really complain about: just be consistent with yourself :) |
...avafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java
Outdated
Show resolved
Hide resolved
...avafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java
Outdated
Show resolved
Hide resolved
...avafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java
Outdated
Show resolved
Hide resolved
...avafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java
Outdated
Show resolved
Hide resolved
...avafx.controls/src/test/java/test/javafx/scene/control/ComboBoxTest.java
Outdated
Show resolved
Hide resolved
looks good :) |
The fix looks good for an editable ComboBox. If the ComboBox is not editable, it will have the effect of making the HOME and END keys no-ops, which is a (possibly unwanted) change in behavior. I checked a couple native Windows apps and they have the behavior I would expect: the arrow keys, and the HOME / END keys navigate the text field for editable combo boxes. HOME and END go to the beginning or end of the list for non-editable combo boxes. While we could treat that as a follow-up issue, it would be worth thinking about whether we could limit the change to editable combo boxes. |
outch .. how did I overlook that .. (seems reviewing doesn't belong to my strengths ;) This fix should not break (correct) existing behavior, so back to thinking .. |
I have updated PR with changes for non editable ComboBox. Also, there is one change in the if condition that was suggested by Jeanette before, It seems safe as |
I haven't tested it, but it looks like it should work. I left a couple of minor suggestions below. Would it be possible to add some tests to verify the behavior of HOME and END for editable and non-editable ComboBox controls? |
...rc/main/java/com/sun/javafx/scene/control/behavior/ListViewBehavior.java
Outdated
Show resolved
Hide resolved
...rc/main/java/com/sun/javafx/scene/control/behavior/ListViewBehavior.java
Outdated
Show resolved
Hide resolved
@kevinrushforth @kleopatra |
hmm .. this is getting unwieldy, isn't it ;) The pain points:
My suggestion would be to take a step back (in solution path): near the beginning was the evaluation of using different inputMaps for different state contexts. Which was not further evaluated because it looked like we could get away with simply configuring the mappings - based on certain condition - once at instantiation time. Which has the advantage of not touching too much code but unfortunely turned out to be not enough. Meanwhile, I'm convinced that in the long run there is no way around different inputMaps based on context: the differences in behavior (stand-alone vs. editable combo-popup vs. not-editable combo-popup) are many - f.i. focus-only navigation doesn't make sense in the popup (should be selection navigation always), left/right in a not-editable should trigger selection navigation .. and certainly more. So we not only have to enable/disable certain mappings, but also re-map the triggered behavior. That's too broad for this issue, but we could take a step into that direction: use the InputMap/Mapping API to help - it was designed for exactly such a differentiation :) The step would be to use interceptors (instead of dynamic modification of the mappings list), they are available on both inputMap and mapping level. As a first step, we could use the latter: keep the addition of mappings as-is (before the fix) and add interceptors to mappings for inclusion/exclusion based on context. No listeners, no dynamic modification, just one marker in the properties .. hopefully :) Raw code snippets:
With this, the tests for key navigation are passing, the low-level mapping tests will have to be re-formulated to test for not/intercepted vs. existence. What do you think? |
Suggestion looks promising, I shall try it and update. |
@kleopatra @kevinrushforth |
Fix looks fine and indeed pretty :) Verified tests failing before and passing after the fix. Left some minor comments inline. |
...rc/main/java/com/sun/javafx/scene/control/behavior/ListViewBehavior.java
Show resolved
Hide resolved
...ntrols/src/main/java/javafx/scene/control/skin/ComboBoxListViewSkin.java
Outdated
Show resolved
Hide resolved
...avafx.controls/src/test/java/test/javafx/scene/control/ComboBoxTest.java
Show resolved
Hide resolved
...avafx.controls/src/test/java/test/javafx/scene/control/ComboBoxTest.java
Outdated
Show resolved
Hide resolved
...avafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java
Outdated
Show resolved
Hide resolved
Updated PR with corrections, please take a look. |
looks good to me now :) |
...avafx.controls/src/test/java/test/javafx/scene/control/ComboBoxTest.java
Show resolved
Hide resolved
@arapte This change now passes all automated pre-integration checks. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 35 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.
|
/integrate |
@arapte Since your change was applied there have been 35 commits pushed to the
Your commit was automatically rebased without conflicts. Pushed as commit 77a183e. |
The issue occurs because the key events are consumed by the
ListView
inPopup
, which displays the items.This is a regression of JDK-8077916. This change aadded several
KeyMapping
s for focus traversals toListView
, which consume theLeft
,Right
andCtrl+A
key events.Fix:
KeyMapping
s fromListViewBehavior
.Ctrl + A
KeyMapping
toListViewBehavior
only if theListView
's selection mode is set toSelectionMode.MULTIPLE
.ComboBox
uses theListView
withSelectionMode.SINGLE
mode.Change unrelated to fix:
ComboBoxListViewBehavior
addsKeyMapping
forUp
andDown
keys, which are not invoked when theComboBox
popup is showing. When the popup is shown, the Up and Down key events are handled by theListView
and theKeyMapping
code fromComboBoxListViewBehavior
does not get executed. These KeyMapping are removed.However this change is not needed for the fix. But this seems to be dead code.
Verification:
Added new unit tests to verify the change.
Also verified that the behavior ListView behaves same before and after this change.
Progress
Issue
Reviewers
Download
$ git fetch https://git.openjdk.java.net/jfx pull/172/head:pull/172
$ git checkout pull/172