8272232: javax/swing/JTable/4275046/bug4275046.java failed with "Expected value in the cell: 'rededited' but found 'redEDITED'." #5079
Conversation
…ted value in the cell: 'rededited' but found 'redEDITED'.
|
|
Webrevs
|
|
I am not sure how it is possible that the shift was pressed while this test tried to type the text, the "redEDITED" mean that initially, the shift was unpressed? Looks like somebody login into the system and accidentally press that button, no? |
|
I am not sure of the actual reason...But I thought physically accessing the system at this time and pressing CAPS will be less possible at this time of pandemic than some test doing something wrong.. |
|
Yes this cleanup looks fine, I just would like to highlight that the actual root cause of this issue is one of:
|
|
@prsadhuk 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 227 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.
|
I don't believe any of the scenarios. As you well know these headful tests will be re-run 2 more times if they fail. It seems improbable some one was sitting there waiting to jump on the keyboard and interfere with the test at the exact moment 3 different times. And the same for a KVM error. As for in parallel we'd have hundreds of failures in such a case and we do not see that And looking at the test log for when this failed 4 tests in total failed and they all have similar problems === java\awt\SplashScreen\MultiResolutionSplash\MultiResolutionSplashTest.java Execution failed: `main' threw exception: java.lang.RuntimeException: Focus is lost! Expected 'ab' got 'AB'. java/awt/Toolkit/RealSync/Test.java Test failed: testType javax/swing/JFileChooser/8041694/bug8041694.java java.lang.RuntimeException: The selected directory name is not the expected 'd ' but 'D '. ====== Moreover this test isn't even the first that failed - that was MultiResolutionSplashTest - so the problem was So some test left SHIFT pressed. I can imagine a timing problem where a test was exited before it managed to release. I am curious how Prasanta decided test/jdk/javax/swing/JRadioButton/8033699/bug8033699.java might be the problem It was executed long after these tests were already failing. So the root cause test is not yet identified. |
But we know the log information only for the last failure, probably the button was pressed only for the last rerun. And according to this log, the shift or capslock was pressed during the test case execution. How it could be? |
Not true ! stdout has everything ! All runs.Just a summary for a pass but all the data for a failure In one contoguous log file so there is no question. |
Ok, so now we know that: according to this "contiguous log", the shift or capslock was pressed during the test case execution a few times in a row. How it could be?" |
|
Actually, the answer is simple. The test edits the cell in the table, the initial text in that cell is "red", the test appended the "edited" text. Since the capslock was enabled the actual result became "redEDITED". |
As I told in initial explanation, I thought it will be either CAPS_LOCK key switched on or some other test did not use SHIFT key corectly ie, pressed but not released. I could not do anything about if someone press CAPS_LOCK so I search for VK_SHIFT being used in all javax/swing reg test and I found this test bug8033699.java is having a wrong order. I am not saying this was the root cause but it needs rectifying, I presume.. |
|
There was one fix done way back regarding almost same tests being failed due to CAPS_LOCK not turned off by test |
This seems the likely cause. And in this case we have to find the test which leaves Shift presses or uses Caps Lock.
In this test, bug8033699.java, the Shift key is released, however, it's released before Tab is released whereas (modifier) keys are usually released in the reverse order to the order they are pressed. Have you already submitted a bug to fix the release order?
Yes, you're right the test is about getting the new text committed into the table cell. Yet the test didn't press Shift key, nor did it turn Caps Lock on, which means the problem is external to the test itself. If Shift key remains pressed, some other test could fails, for example, bug8033699.java will liked fail if it's started with Shift key press because focus will be traversed in the reverse order rather than forward order. |
| @@ -175,6 +177,7 @@ private void checkResult() throws Exception { | |||
| public void run() { | |||
| // Read the edited value of from the cell | |||
| editedValue = table.getModel().getValueAt(0, 1); | |||
| editedValue = ((String)editedValue).toLowerCase(); | |||
There was a problem hiding this comment.
So this just masks that some other test is the real problem.
|
I think what you need to do is take the list of tests that were run before the FIRST failure - not this one. Then work (backwards) through those to see which might have let SHIFT down which may be harder. One thing I don't know (or understand) is why some other test that presses SHIFT did not release it and solve the problem. Oh, and finding prior tests which would have failed if SHIFT was down but "pass" might also help the search. |
|
Since FIRST failure is java/awt/SplashScreen/MultiResolutionSplash/MultiResolutionSplashTest.java and CAPS_LOCK keys I could not find any misuse of VK_SHIFT apart from in For CAPS_LOCK, LockingKeyState was already rectified as I mentioned in previous comment and |
| robot.keyRelease(KeyEvent.VK_CONTROL); | ||
| robot.keyRelease(KeyEvent.VK_SHIFT); | ||
| robot.keyRelease(KeyEvent.VK_ALT); | ||
| dispose(); | ||
| throw new RuntimeException("Action Event modifiers are not" | ||
| + " set correctly."); |
There was a problem hiding this comment.
This exception should be thrown from the main thread. An action listener is called on EDT, thus the exception won't fail the test, will it?
And using robot to release keys from EDT as part of the clean-up doesn't seem right.
There was a problem hiding this comment.
And using robot to release keys from EDT as part of the clean-up doesn't seem right.
I am just rectifying the order of the key release..It was pressed in order ALT SHIFT CONTROL and the release was ALT SHIFT CONTROL.. which I rectified to be release in order CONTROL SHIFT ALT
| if (selectedDir.getName().equals("d")) { | ||
| if (selectedDir.getName().toLowerCase().equals("d")) { | ||
| throw new RuntimeException( | ||
| "JFileChooser removed trailing spaces in the selected directory name. " + | ||
| "Expected 'd ' got '" + selectedDir.getName() + "'."); | ||
| } else if (!selectedDir.getName().equals("d ")) { | ||
| } else if (!selectedDir.getName().toLowerCase().equals("d ")) { |
There was a problem hiding this comment.
I believe @prrace's comment also applies here: So this just masks that some other test is the real problem.
Can you reproduce the failure locally if the tests are run in the same order? |
Yes and no. These tests fail in my local system but not with same error message. Also, I admit that the test changes are masking this timing issues, but the changes are not wrong. If the original test author had used toLowerCase() initially, I don't think anyone would have objected as the test just checks for new characters without any distinction between lowercase/uppercase and this change would prevent this swing tests from failing. |
Yeah, I know. Local environment is usually faster and more responsive.
Do you mean that none of these tests has failed recently?
I don't see why the original author would've bothered with The test doesn't fail if it's run outside the long running test suite, does it? This means the test is correct as it is written now, its failure is caused by another misbehaving test which most likely has left Shift key pressed. As an experiment, is it possible to log the current state of modifier keys, i.e. Shift, Control, Alt, before the key events are sent to edited table cell? This would confirm our guess whether Shift key is left pressed by a test which ran before. To be clear, I'm not objecting this change, however, it doesn't feel right to me. At the same time, it's the quickest way to make the test pass. I'm pretty sure most of the tests dealing with text input don't use |
It seems Toolkit.getLockingKetState() can only be called for CAPS_LOCK, NUM_LOCK, SCROLL_LOCK etc and not for modifiers. So, modifier keys can only be obtained from InputEvent. I used my own event listener inside the MultiResolutionSplashTest to get shift key via isSHiftDown() and run whole java_awt test in CI and it is shown to be "false" in that test so it seems no shift key is pressed at least for this run. Maybe someother thing or some other timing issues happened the time these test fails. |
|
/issue add 8257540 |
|
@prsadhuk |
|
/integrate |
|
Going to push as commit cec6c06.
Your commit was automatically rebased without conflicts. |
openjdk
bot
added
integrated
The test fails in CI testing citing expected "rededited" but found "redEDITED", which seems to point to fact that either there is a CAPS_LOCK key switched on or some other test did not use SHIFT key corectly ie, pressed but not released.
Considering many more tests would have failed if CAPS_LOCK is turned on, I tried to find if some tests uses SHIFT key mistakenly and it seems JRadioButton test has press/release order wrong and it uses SHIFT. Rectified that.
In addition, corrected some known CI issues ie waiting after frame is made visible, made frame to centre. Along with that, also modified testcase to check lowercase string. Since the original JDK-4275046 issue is about newly entered text is made part of cell or not, it does not matter if it's in lowercase/uppercase and if such CAPS_LOCK or Shift key problem happens again, this test will not be affected.
CI run for several iterations running these 2 tests one after another in all platforms is green.
Progress
Issues
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/5079/head:pull/5079$ git checkout pull/5079Update a local copy of the PR:
$ git checkout pull/5079$ git pull https://git.openjdk.java.net/jdk pull/5079/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 5079View PR using the GUI difftool:
$ git pr show -t 5079Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/5079.diff