On Tue, 29 Jul 2025 14:45:36 GMT, Martin Fox <m...@openjdk.org> wrote:
> This PR fixes numerous bugs in the handling of setMaximized() on macOS and > also cleans up some issues seen when the user changes the maximized state > manually. > > - After setMaximized(false) a notifyResize event was never sent so the width > and height tracked by JavaFX was wrong. > > - During maximize and restore a series of notifyMove events were issued > causing the maximized property to flip-flop during the animation. > > - Transparent windows were being maximized by passing native screen > coordinates to a routine that expected JavaFX screen coordinates so the Y > axis was flipped and the window was positioned incorrectly. > > - The restored frame is in native screen coordinates which was sent to a > routine that expected flipped JavaFX coordinates. That routine corrected this > by directly inspecting the call stack to see which routine was calling it. > > - When the user maximizes or restores the window a notifyResize event was > always sent immediately stating that the window was maximized even when it > was not. Then a series of notifyMove events were issued causing the maximized > flag to flip-flop during the animation. > > This PR cleans all of this up. When using the setMaximized API only one > notifyMove and one notifyResize event are sent and transparent windows are > positioned correctly. When the user maximizes or restores manually we still > see a series of notifyMove and notifyResize events but at least they all > report the window’s state correctly. > > System tests are currently being written as part of #1789. It’s hard to > create a system test that catches things like the mis-alignment of maximized > transparent windows so that needs to be tested manually. The reproducer > attached to the bug report can be used to verify this and also to see what > happens when the user toggles the maximization state manually. > > Note that when the test programs tags something as “unexpected” it just means > it saw a property change outside of any JavaFX API call. This is actually > expected if the user manipulates the window manually. @beldenfox It might be better to close [JDK-8179980](https://bugs.openjdk.org/browse/JDK-8179980) as a duplicate of this bug (JDK-8355990) rather than add it as a separate issue, since it is a natural step when fixing the underlying product bug to re-enable any skipped tests. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1860#issuecomment-3136751033
