On Tue, 29 Jul 2025 14:45:36 GMT, Martin Fox <[email protected]> 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.
modules/javafx.graphics/src/main/native-glass/mac/GlassWindow.m line 1047:
> 1045: int eventType = com_sun_glass_events_WindowEvent_RESTORE;
> 1046:
> 1047: if ((maximize == JNI_TRUE) && (isZoomed == JNI_FALSE)) {
changing this code to K&R style messes up the diff alignment... could we
retain the original style?
tests/system/src/test/java/test/javafx/stage/RestoreStagePositionTest.java line
130:
> 128:
> 129: Platform.runLater(() -> stage.setMaximized(true));
> 130: Thread.sleep(800);
Would the `test.util.Util.waitForIdle()` be of use here? Or `runAndWait()` ?
-------------
PR Review Comment: https://git.openjdk.org/jfx/pull/1860#discussion_r2243908044
PR Review Comment: https://git.openjdk.org/jfx/pull/1860#discussion_r2243913600
