8235480: Regression: [RTL] Arrow keys navigation doesn't respect TableView orientation #114
Conversation
|
👋 Welcome back aghaisas! A progress list of the required criteria for merging this PR into |
aghaisas
changed the title
Webrevs
|
...vafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/TableViewBehaviorBase.java
Outdated
Show resolved
Hide resolved
...vafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/TableViewBehaviorBase.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
@kleopatra is right about the need to handle the case where the orientation of a node changes. As for the test, I think the idea of parameterizing it with LTR, RTL is good. I haven't reviewed it in detail, but added one minor suggestion for you to consider.
...vafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/TableViewBehaviorBase.java
Outdated
Show resolved
Hide resolved
modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewKeyInputTest.java
Outdated
Show resolved
Hide resolved
|
/reviewers 2 |
|
@kevinrushforth |
|
|
||
| if (orientation == NodeOrientation.LEFT_TO_RIGHT) { | ||
| keyboard.doRightArrowPress(KeyModifier.getShortcutKey()); | ||
| keyboard.doRightArrowPress(KeyModifier.getShortcutKey()); | ||
| } else if (orientation == NodeOrientation.RIGHT_TO_LEFT) { | ||
| keyboard.doLeftArrowPress(KeyModifier.getShortcutKey()); | ||
| keyboard.doLeftArrowPress(KeyModifier.getShortcutKey()); | ||
| } |
There was a problem hiding this comment.
having such if blocks in all tests regarding horizontal navigation feels like the parametrization isn't quite complete, IMO: the test method shouldn't need to worry, instead just call semantic horizontal navigation methods.
A simple change would be to extract that differentiation into a dedicated method, like f.i. forward/backward, test would get simpler (and make it easier to add those that are missing :)
@Test
public void testForwardFocus() {
sm.setCellSelectionEnabled(true);
sm.select(0, col0);
// current
//if (orientation == NodeOrientation.LEFT_TO_RIGHT) {
// keyboard.doRightArrowPress(KeyModifier.getShortcutKey());
//} else {
// keyboard.doLeftArrowPress(KeyModifier.getShortcutKey());
//}
// extracted
forward(KeyModifier.getShortcutKey());
assertTrue("selected cell must still be selected", sm.isSelected(0, col0));
assertFalse("next cell must not be selected", sm.isSelected(0, col1));
TablePosition focusedCell = fm.getFocusedCell();
assertEquals("focused cell must moved to next", col1, focusedCell.getTableColumn());
}
/**
* Orientation-aware horizontal navigation with arrow keys.
* @param modifiers the modifiers to use on keyboard
*/
protected void forward(KeyModifier... modifiers) {
if (orientation == NodeOrientation.LEFT_TO_RIGHT) {
keyboard.doRightArrowPress(modifiers);
} else {
keyboard.doLeftArrowPress(modifiers);
}
}
There was a problem hiding this comment.
Also, I'm a bit weary about the "else if" (vs a simple "else") - wouldn't it be some kind of setup error if the node orientation is neither rtl nor ltr? If so, I would add a test to check for it once.
There was a problem hiding this comment.
Initially I had thought about adding separate test file for RTL - something like RTLTableViewKeyInputTest - but, realized that although it's a cleaner approach, we would simply duplicate the tests. Also, the fact is only LEFT/RIGHT key navigation is sensitive to NodeOrientation - hence only a subset of tests needed modification. This is the reason I have parameterized the test.
To your specific question, since it is a parameterized test, only possible values are LTR and RTL which are specified as @Parameterized.Parameters. I don't think, we need additional check for some other value.
There was a problem hiding this comment.
Regarding your suggestion of having forward/backward semantic methods and calling them in tests -
There are two types of tests -
- Key action remains same - asserts differ based on NodeOrientation
- Key action differs based on NodeOrientation - but, asserts remain same
Example of 1 is - test_rt18488_selectToLeft
Example of 2 is - test_rt18591_cell_1
Your suggestion can be applied only to the tests of type-2. I will try to update tests of this type.
There was a problem hiding this comment.
ahh .. okay, missed that difference, thanks :)
Hmm, still feels smelly to have to use the parameter for conditional branches (either on the assumption or on the navigation). Will check later
There was a problem hiding this comment.
and yes, agree with using parameterized tests at all ... just have this nagging feeling that it's not quite done to the end :)
|
After digging a bit, a couple of notes (not entirely certain if this here is the correct place for them?) Changing existing tests Don't know what the culture in the fx context is, but: personally I prefer to not touch existing methods. Obvious reason is that I might break a test or test the wrong thing or tweak it in any way that makes it rather useless. An example of testing the wrong thingy on changing a test method might be test_rt18488_selectToLeft (guard against JDK-8120174). The report describes the misbehaviour as
the block added for the rtl variant does test something else for
Parameterized Tests repeating earlier comments (just to have it here for reading convenience): the goal of the parameterization is to make the test code (mostly) unaware of the parameters. In particular, if I feel the need for conditional test blocks - either in setup or in assert blocks - on the parameters, I often find out that something went wrong with the factoring. Not written in stone, though, could be me only :) Alternative My preference would be to not touch TableViewKeyInputTest at all, but to add a new test class exclusively for testing orientation-dependent horizontal navigation by keyboard. It should focus on what's actually changed, that is the basic left/right/extend/shrink etc navigation and dynamic change of those. The class can be parameterized, the parameter being a triplet of orientation and forward/backward keys. The emphasis on basic is intentional: I think that there is no need to cover all existing tests against bug reports nor more evolved navigation. Given all basic mappings are working as expected, everything built on top should work as well - might be wrong or there might be exceptions :) For a bit of clarity - hopefully- of what I mean, I put togeter a raw poc example TableViewHorizontalArrowsTest) |
|
Thanks @kleopatra for thinking through clearly about testing and providing a simpler test approach with PoC.
I have done modifications to the PoC code provided and added this test in latest commit.
|
There was a problem hiding this comment.
I think the fix looks good and the approach you took for the new test looks good to me. If @kleopatra is OK with it, then please proceed.
I left a couple minor comments.
...vafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/TableViewBehaviorBase.java
Show resolved
Hide resolved
...s/javafx.controls/src/test/java/test/javafx/scene/control/TableViewHorizontalArrowsTest.java
Outdated
Show resolved
Hide resolved
| import test.com.sun.javafx.scene.control.infrastructure.StageLoader; | ||
|
|
||
| /** | ||
| * Test basic horizontal navigation mappings for TableView. It's parametrized on NodeOrientation |
There was a problem hiding this comment.
Typo: should be parameterized
...s/javafx.controls/src/test/java/test/javafx/scene/control/TableViewHorizontalArrowsTest.java
Outdated
Show resolved
Hide resolved
Well, I disagree with your notion of "simpler" - replacing conditional blocks in tests by parameterized tests is the whole point of these. But at the end of the day, it's probably a matter of personal preferences :)
the difference between my and your code in changeNodeOrientation is that mine only changes the table's orientation and yours additionally changes the parameter nodeOrientation - resulting in your navigational methods using keys based on the orientation while mine uses those for the old orientation. Changing the parameter smells, IMO.
agreed on the overall approach, will add a couple of inline comments |
...s/javafx.controls/src/test/java/test/javafx/scene/control/TableViewHorizontalArrowsTest.java
Outdated
Show resolved
Hide resolved
...s/javafx.controls/src/test/java/test/javafx/scene/control/TableViewHorizontalArrowsTest.java
Outdated
Show resolved
Hide resolved
...s/javafx.controls/src/test/java/test/javafx/scene/control/TableViewHorizontalArrowsTest.java
Outdated
Show resolved
Hide resolved
...s/javafx.controls/src/test/java/test/javafx/scene/control/TableViewHorizontalArrowsTest.java
Outdated
Show resolved
Hide resolved
|
@aghaisas can't see your last response here (looks like I'm fighting the system here - and loosing again ;) So copying from the mailing list:
good move!
yeah, I agree - with a minor matter: the dynamic change testing is for a single key combination only. Personally, I prefer test completeness to really grab all changes (here all key combinations): future maintainers sometimes have ideas (f.i. inlining the isRTL, and accidentally not doing it on the simple keys) which they should be protected from doing - up to you, though. Assuming that Behaviours will move into public scope, shouldn't public/protected api documented when added (as isRtL())? Not sure about fx team internal conventions. Anyway, all side-thought, so feel free to commit |
There was a problem hiding this comment.
Looks good to me.
This needs one more reviewer. @kleopatra would you be willing?
|
@aghaisas 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 28 commits pushed to the ➡️ To integrate this PR with the above commit message, type |
|
/integrate |
openjdk
bot
added
integrated
|
@aghaisas The following commits have been pushed to master since your change was applied:
Your commit was automatically rebased without conflicts. Pushed as commit 2aa8218. |
Bug : https://bugs.openjdk.java.net/browse/JDK-8235480
Fix : Added the missed out RTL checks to the key mappings in TableViewBehaviorBase class.
Testing : Added a test to take NodeOrientation as a parameter and test horizontal key navigation for the TableView.
Progress
Issue
Reviewers
Download
$ git fetch https://git.openjdk.java.net/jfx pull/114/head:pull/114$ git checkout pull/114