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> 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> 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> 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> 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> 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 MaximizeLinuxBugextends 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 StringcreateCss() {
return """ * { -fx-border-color: red;
-fx-border-width: 1; } """;
}
private RegioncreateContent() {
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
