On Thu, 31 Jul 2025 15:05:20 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. > > Martin Fox has updated the pull request incrementally with one additional > commit since the last revision: > > Cleaned up diff against master. Tighted up system test (tested on Windows > and Linux) Tested various scenarios on macOS 15.5 with the reproducer and the (updated) monkey tester from https://github.com/andy-goryachev-oracle/MonkeyTest , works as expected. Finally, can remove the hack from https://github.com/andy-goryachev/FxDock/blob/5d1128bd56a60d56ab743aa7c4f830bc248cc343/src/goryachev/fx/settings/WindowMonitor.java#L147 Many thanks! ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1860#pullrequestreview-3077116426
