Christopher — Thanks for the details. Thiago — I’m still of the opinion that we shouldn’t try to specify what happens when a client tries to resize a maximized window. I don’t like leaving these things unspecified but I’m not sure there’s a compelling use case that would justify the effort involved in nailing this down. Simpler to just document that the window should be de-maximized first.
I’m also seeing some bugs on macOS related to maximizing and de-maximizing the window and it looks like we don’t have good system tests for some of this (or they’re disabled). Personally I would rather focus on fixing those issues. Martin > On Apr 17, 2025, at 10:44 PM, Christopher Schnick <crschn...@xpipe.io> wrote: > > I wasn't really trying it, our application just had functionality to resize > the window on a certain action. And this functionality then broke the window > content when triggered while the window was maximized, which is a case I > didn't consider. I implemented a workaround for this now by just setting the > maximized property to false prior and only resizing the window if really > necessary, but I can imagine other applications possibly being affected by > this. > > For reference, here is a video on how the issue looked like initially on > Linux: https://github.com/xpipe-io/xpipe/issues/485 > > On 17/04/2025 22:24, Martin Fox wrote: >> Christopher, >> >> Why are you trying to change the size of a maximized stage? I’m not sure >> what the intended effect is. >> >> Currently this produces all sort of platform-specific behavior and since >> what you’re seeing on Windows doesn’t match what I’m seeing I think there >> might be some variation based on OS version. The easiest way out of this >> thicket is to de-maximize the stage before trying to change its size. >> >> With that said, yes, this Linux bug definitely needs to be fixed. Whatever >> happens the scene shouldn’t break. >> >>> On Apr 16, 2025, at 3:32 AM, Thiago Milczarek Sayão >>> <thiago.sa...@gmail.com> <mailto:thiago.sa...@gmail.com> wrote: >>> >>> Hi, >>> >>> I’d like to get your thoughts on what the expected behavior should be when >>> setting the size of a window while it's in a maximized state. >>> >>> Here are the options I’ve considered: >>> >>> a) Ignore the resize while maximized, and when restored, revert to the size >>> before it was maximized >>> b) Demaximize the window and apply the new size immediately >>> c) Ignore the resize request, but store the values and apply them upon >>> restore >> >> Option A forces the client to de-maximize the window before changing its >> size. Option B de-maximizes the window automatically. Option C is the only >> one that brings new functionality to the table but it would be complicated >> to implement (assuming it can be implemented). >> >> The documentation states that this is how things work when a stage is in >> fullscreen mode but from I can tell that’s not how any of the platforms >> actually behave. Trying to resize a fullscreen window produces a variety of >> immediate platform-specific effects. >> >>> If I understood correctly, Martin mentioned that both macOS and Windows >>> apply the resize immediately while keeping the window maximized. >> >> You understood correctly but I was wrong. On Windows 11 the size changes >> (I’m seeing only one resize event) and the window stays in the maximized >> state. This seems to be confusing the OS and it draws the title bar >> incorrectly. On macOS the size changes and the window leaves the maximized >> state but due to a bug in the code we don’t update the maximized property >> correctly. >> >> Martin >> >>> Then, when the window is demaximized, it restores the previous >>> (pre-maximized) size, which suggests behavior leaning toward option a. >>> >>> For fullscreen mode, the expected behavior appears to align more with >>> option c, as documented for Stage fullscreen. >>> >>> -- Thiago. >>> >>> >>> Em sáb., 29 de mar. de 2025 às 09:24, Thiago Milczarek Sayão >>> <thiago.sa...@gmail.com <mailto:thiago.sa...@gmail.com>> escreveu: >>>> I did not find a bug report, so I did one and provided a fix: >>>> >>>> https://github.com/openjdk/jfx/pull/1748 >>>> >>>> >>>> >>>> Em sáb., 29 de mar. de 2025 às 08:26, Thiago Milczarek Sayão >>>> <thiago.sa...@gmail.com <mailto:thiago.sa...@gmail.com>> escreveu: >>>>> @Christopher Schnick <mailto:crschn...@xpipe.io> >>>>> >>>>> Hi, did you open a bug? I have a fix for this. >>>>> >>>>> Thanks >>>>> >>>>> -- Thiago. >>>>> >>>>> Em seg., 17 de mar. de 2025 às 09:49, Christopher Schnick >>>>> <crschn...@xpipe.io <mailto:crschn...@xpipe.io>> escreveu: >>>>>> So on Windows at least, it will change the width temporarily and then >>>>>> revert back to the original width value. So you will receive two width >>>>>> change events if you listen to the stage width property. The maximized >>>>>> property is not changed. >>>>>> >>>>>> I guess this also not optimal handling of this. Ideally, no changes >>>>>> would be made in that case. >>>>>> >>>>>> On 17/03/2025 10:53, Thiago Milczarek Sayão wrote: >>>>>>> Hi Christopher, >>>>>>> >>>>>>> It seems like a simple fix. >>>>>>> >>>>>>> How does it behave on other platforms? Does it ignore the resize, >>>>>>> restore the window to its unmaximized state before resizing, or keep it >>>>>>> maximized while adjusting the unmaximized size. >>>>>>> >>>>>>> -- Thiago >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Em dom., 16 de mar. de 2025 às 05:25, Christopher Schnick >>>>>>> <crschn...@xpipe.io <mailto:crschn...@xpipe.io>> escreveu: >>>>>>>> Hello, >>>>>>>> >>>>>>>> we encountered an issue on Linux where resizing the stage while it is >>>>>>>> maximized breaks the size of the scene. You can see a video of this at >>>>>>>> https://github.com/xpipe-io/xpipe/issues/485 . The root cause is that >>>>>>>> the stage size is modified. >>>>>>>> >>>>>>>> When doing this, it temporarily or permanently switches to the size >>>>>>>> the stage had prior to being maximized, leading to either a flicker or >>>>>>>> a permanently broken scene that has the wrong size. This happens on >>>>>>>> Gnome and KDE for me with the latest JavaFX ea version. >>>>>>>> >>>>>>>> Here is a simple reproducer: >>>>>>>> >>>>>>>> import javafx.application.Application; >>>>>>>> import javafx.scene.Scene; >>>>>>>> import javafx.scene.control.Button; >>>>>>>> import javafx.scene.layout.Region; >>>>>>>> import javafx.scene.layout.StackPane; >>>>>>>> import javafx.stage.Stage; >>>>>>>> >>>>>>>> import java.io.IOException; >>>>>>>> import java.util.Base64; >>>>>>>> >>>>>>>> public class MaximizeLinuxBug extends Application { >>>>>>>> >>>>>>>> @Override >>>>>>>> public void start(Stage stage) throws IOException { >>>>>>>> Scene scene = new Scene(createContent(), 640, 480); >>>>>>>> var s = "data:text/css;base64," <> + >>>>>>>> Base64.getEncoder().encodeToString(createCss().getBytes()); >>>>>>>> scene.getStylesheets().add(s); >>>>>>>> stage.setTitle("Hello!"); >>>>>>>> stage.setScene(scene); >>>>>>>> stage.show(); >>>>>>>> stage.centerOnScreen(); >>>>>>>> stage.setMaximized(true); >>>>>>>> } >>>>>>>> >>>>>>>> private String createCss() { >>>>>>>> return """ >>>>>>>> * { >>>>>>>> -fx-border-color: red; >>>>>>>> -fx-border-width: 1; >>>>>>>> } >>>>>>>> """; >>>>>>>> } >>>>>>>> >>>>>>>> private Region createContent() { >>>>>>>> var button = new Button("Click me!"); >>>>>>>> button.setOnAction(event -> { >>>>>>>> var w = button.getScene().getWindow(); >>>>>>>> w.setWidth(w.getWidth() - 1); >>>>>>>> event.consume(); >>>>>>>> }); >>>>>>>> var stack = new StackPane(button); >>>>>>>> return stack; >>>>>>>> } >>>>>>>> >>>>>>>> public static void main(String[] args) { >>>>>>>> launch(); >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> Best >>>>>>>> Christopher Schnick >>>>>>>> >>
