RFR: 8356061: [macos] com/apple/laf/RootPane/RootPaneDefaultButtonTest.java test fails on macosx-aarch64 machine [v3]

Alexey Ivanov aivanov at openjdk.org
Wed May 21 12:41:57 UTC 2025


On Mon, 19 May 2025 05:37:05 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> Unfortunately I'm unable to reproduce this failure. I slowed the test down; it passes on my machine before and after this PR.
>> 
>> I added a little bit of logging that might also help identify what's happening.
>> 
>> Does anyone have any more suggestions?
>
> Jeremy Wood has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8356061: removing robot
>   
>   This is in response to:
>   https://github.com/openjdk/jdk/pull/25244#issuecomment-2889420453

> > Is it possible that the button hovered by mouse looks the same way as the default one?
> 
> That's the big question this unit test is trying to answer. (So: I'm not sure.)
> 
> > Did the original test move the mouse before getting pixel color of a button?
> 
> Yes.
>
> If that was the problem: all we needed to do is delete this call to `robot.mouseMove`.

So, the mouse cursor hovered over the button… which could essentially make a non-default button look the same way as the default button… because it's hovered.

I don't have a Mac to test it right away, but on Windows the default button has a brighter border and a slightly bluish background; hovering over any button gives it the same border and a blue background.

> (But even so: I think the cursor on Mac is black -- so why would we detect a gray 0x373737 ?)

The cursor isn't always captured…

---

> > It may also be worth pointing out: this test has never failed. It was added as an extra precaution, but not because it demonstrated a fix for anything. I would not miss it if we delete it; I don't think it deserves the time spent discussing/refactoring it.
>
> Just deleting robot.mouseMove(x, y) might also resolve the issue seen in our test environment.

Yeah, likely removing `mouseMove` would resolve the failure.

> But the current refactoring using BufferedImage is better than using Robot and deleting mouseMove() call.

It's always better, in my opinion… I just wonder whether this test has any value. But I haven't looked thoroughly enough into either of the fixes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25244#issuecomment-2897823434


More information about the client-libs-dev mailing list