-
Notifications
You must be signed in to change notification settings - Fork 6.1k
8341984: Use PassFailJFrame for TimeChangeButtonClickTest.java #21476
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closed
aivanov-jdk
wants to merge
3
commits into
openjdk:master
from
aivanov-jdk:8341984-PassFailJFrame-TimeChangeButtonClickTest.java
Closed
Changes from all commits
Commits
Show all changes
3 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We do have a pause timer option but I think a timeout of 8-10 mins is better than the default of 5 mins since it allows more time for the user to change the time settings.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, I think what is happening is that when the time is set forward an hour (+2 hours forward from 1 hour behind as in instructions) the test will automatically time out because it thinks an hour has passed. I thought initially it was me being slow on changing the time settings but even if you do everything quickly the test always fails exactly when you set the time forward.
So I think with the way the timeout is implemented the test is broken with PassFailJFrame.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What an .. interesting .. test. No idea what this does to the jtreg test harness too.
FWIW I think this test should be deleted rather than trying to make it nicer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch. I hadn't noticed PFJ timeout.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed, the test does not play nicely with timeout in
PassFailJFrame
.The workaround could be to pause the timeout. In addition to that, we could set the timeout to 15 minutes. If the user changes time not -1 / +2 hours but rather -5 / +10 minutes, it should be enough.
The jtreg test harness turns off its timeout for manual tests, as far as I understand. By the time, the test finishes, the time on the system should be correct again.
Another option could be to mark the test with
@ignore
so that it's not run regularly. The test could still be useful; even though changing time isn't common…I wonder if going to/from DST reproduces the problem in JDK-7096375 for which the test was written.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The workaround sounds good and may be also include pause timer in the test instructions as below.
Yes I agree, retaining the test might be a good idea since it was created for -
JDK-7096375.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good for a workaround.