-
Notifications
You must be signed in to change notification settings - Fork 5.8k
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
8294254: [macOS] javax/swing/plaf/aqua/CustomComboBoxFocusTest.java failure #10626
8294254: [macOS] javax/swing/plaf/aqua/CustomComboBoxFocusTest.java failure #10626
Conversation
👋 Welcome back dnguyen! A progress list of the required criteria for merging this PR into |
Suggestion: Does running the test - CustomComboBoxFocusTest.java with uiScale always set to 1 make it more robust? |
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.
Its good that JComboBox misalignment issue is resolved under : https://bugs.openjdk.org/browse/JDK-8054572(I used to observe this at all places in SwingSet2 while testing Lanai)
I ran javax/swing/plaf/aqua/CustomComboBoxFocusTest.java without this change in built-in display and external display:
Built-in display(uiScale 2) : Fails 1/5 times
External display(uiScale 1) : Fails 3/5 times
Initially i was also under the impression that display scaling in test might be the root cause and making it run at some default scaling will solve the issue. But looks like this is a product regression introduced with fix under https://bugs.openjdk.org/browse/JDK-8054572.
Since the current fix takes care of both https://bugs.openjdk.org/browse/JDK-8054572 & https://bugs.openjdk.org/browse/JDK-8073001. This product change looks good to me.
@DamonGuy This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. 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 81 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. 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 (@jayathirthrao) but any other Committer may sponsor as well. ➡️ To flag this PR as ready for integration with the above commit message, type |
Additionally if we want to make javax/swing/plaf/aqua/CustomComboBoxFocusTest.java run at some default uiScale that also should be fine. |
height - (insets.top + insets.bottom)); | ||
} | ||
else { | ||
return new Rectangle(insets.left + buttonSize, insets.top + midHeight, | ||
width - (insets.left + insets.right + buttonSize) + 4, | ||
width - (insets.left + insets.right + buttonSize) + 3, |
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.
I guess previous to this fix, we were using BasicComboBoxUI#rectangleForCurrentValue() which returns a width on which we add +4 for editor/textField width.
Since the calculation is basically same for width, why was it giving problem now (where only height is modified in the 8054572 fix) and not before this fix. I dont think this test use to fail before this fix was integrated with promoted CI builds
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.
Previously, editable comboboxes on macOS were misaligned altogether. The button and textfield were not at the same height (as seen on the "before" screenshots in https://bugs.openjdk.org/browse/JDK-8054572). My assumption is that these pixels that would normally overlap are no longer overlapping because of this.
Sure, I can add a uiscale of 1 for robustness. Seems like a good idea since Jay's results at different uiscales may show variable pass rates at different uiscales. |
…Guy/jdk into 8294254/overlapFixEditableCombobox
|
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.
Looks fine
/integrate |
@jayathirthrao Could you please sponsor this PR? |
/sponsor |
Going to push as commit 358ac07.
Your commit was automatically rebased without conflicts. |
@jayathirthrao @DamonGuy Pushed as commit 358ac07. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
The previous change to AquaComboBoxUI had 1 pixel of overlap between the text field and the combo button. This caused a few pixels to darken sometimes when an editable combobox is displayed. Since this test passes sometimes and fails some other times, it was not initially detected.
Since these few darkening pixels occur due to the change in AquaComboBoxUI, no reasonable change to the test could really be made, and the change would need to be to the class for the combobox. This fix was tested with a high count repeat and no failures occurred for various macOS systems.
Also removing the test from the problem list.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/10626/head:pull/10626
$ git checkout pull/10626
Update a local copy of the PR:
$ git checkout pull/10626
$ git pull https://git.openjdk.org/jdk pull/10626/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 10626
View PR using the GUI difftool:
$ git pr show -t 10626
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/10626.diff