Bug ID: JDK-8316423 [linux] Secondary Stage does not respect Scene's dimensions when shown

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

Other
jfx22 b17Fixed

This issue came out as a part of recently added Stage Attributes test (see related issue).

When a new Stage is created (not the one supplied via Application.start() ), its dimensions are different than declared inside Scene constructor. It also reports width/height via API as intended, however the actual window dimensions are not reflecting that.

Running attached test program shows two Stages - the bottom one is provided via start() argument and it properly accepts the dimensions from the Scene (in test program case, 400x400). Top stage is created right after the bottom one is set up, with the same parameters (400x400 scene). However, its dimensions are half of what they are supposed to be (see attached picture).

Issue happened on Fedora 38 (Linux 6.4) VM with X11 window system. Attached program works properly on Windows.

Changeset: 21f12c18 Author: Thiago Milczarek Sayao <tsayao@openjdk.org> Date: 2023-11-04 16:33:34 +0000 URL: https://git.openjdk.org/jfx/commit/21f12c18369358bf2228aa5c8151c550ff082c66
04-11-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jfx/pull/1249 Date: 2023-09-28 00:31:59 +0000
28-09-2023
We are receiving configure events from outside our scope (we don't request it) that tells the window to go 200x200 (plust 37 for the titlebar).But with a pure gtk C test app it does not happen, so something is triggering this. It happens after the window is configured for 400x400. So it goes to the right size and something request it to be 200x200.
27-09-2023
Sure, I will look into it.
26-09-2023
[~tsayao] Would you be able to take a look at this one too?
25-09-2023
I double-checked this and the problem also exists on Wayland (originally I tested this only on X.org), Fedora 38 and Ubuntu 23.04.
19-09-2023
Actually, we are supposed to run on the latest non-LTS Ubuntu as well. So this is a real problem that we will need to address.
19-09-2023
That snippet does change what dimensions are reported. In my case the first one has 400x437 but secondary stage is reported as 200x237. There must have been some change in window managers between Ubuntu 22.04 LTS and now - I tested this just now on non-LTS Ubuntu (23.04) and the result is the same as on Fedora, secondary Stage shows smaller with 200x237 dimensions instead of 400x437. While I'm aware we do not support anything other than non-LTS Ubuntu versions, this might be a problem-to-come once 24.04 LTS comes out.
19-09-2023
This is likely specific to the window manager being used on Fedora. I ran the attached test program on Ubuntu 22.04 and it works as expected. Btw, the test program prints out the size of the stage too early, and thus doesn't reliably account for any window-system decoration. If you replace the "onShown" block with: StringExpression strProp = Bindings.concat( "w: ", stage.widthProperty().asString(), " h: ", stage.heightProperty().asString()); dims.textProperty().bind(strProp); then it will track the size as the window is configured by the window manager. I get "w: 400.0 h: 437.0" on both stages.
18-09-2023

Relates :	JDK-8298500 - Create test to initially show stage with various attributes (iconified, maximized, full screen)
Relates :	JDK-8316425 - [linux] Stage.setMaximized() before show() does not persist