On Mon, 10 Oct 2022 18:41:24 GMT, Damon Nguyen <[email protected]> wrote:
>> 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.
>
> Damon Nguyen has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contains four commits:
>
> - Merge branch 'master' into 8294254/overlapFixEditableCombobox
> - Merge branch 'openjdk:master' into 8294254/overlapFixEditableCombobox
> - Remove test from problem list
> - Adjust rect width to remove overlap
src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxUI.java line 478:
> 476: else {
> 477: return new Rectangle(insets.left + buttonSize,
> insets.top + midHeight,
> 478: width - (insets.left + insets.right +
> buttonSize) + 3,
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
-------------
PR: https://git.openjdk.org/jdk/pull/10626
