8332222: Linux Debian: Maximized stage shrinks when opening another stage

[tsayao]

This fixes two bugs appointed on the JBS issue:

1. Sometimes window was moving to the top left corner - seems to be a bug somewhere in gdk_window_get_origin when used before map (a X concept when the window appears). The change is to ignore the configure events (happens when location or size changes) until window is mapped. Before map java is notified in the set_bounds function.

This seems to happen on newer versions of linux distros.

2. Specific to KDE, in the case of the example provided, when an MODAL window pops, it calls set_enabled false on the child (or all other windows if APPLICATION_MODAL) which causes it to update the window constraints. When maximized, the constraints where applied anyways, causing the window to still be maximized but not show as maximized. The change is to not apply constraints when not floating (meaning floating on the screen - not maximized, fullscreen or iconified).

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed (2 reviews required, with at least 1 Reviewer, 1 Author)

Issue

• JDK-8332222: Linux Debian: Maximized stage shrinks when opening another stage (Bug - P4)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jfx.git pull/1460/head:pull/1460
$ git checkout pull/1460

Update a local copy of the PR:
$ git checkout pull/1460
$ git pull https://git.openjdk.org/jfx.git pull/1460/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 1460

View PR using the GUI difftool:
$ git pr show -t 1460

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jfx/pull/1460.diff

Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back tsayao! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[mlbridge]

Webrevs

• 02: Full - Incremental (bb9a90b9)
• 01: Full - Incremental (7f6221a2)
• 00: Full (b3c7f407)

[karthikpandelu]

I was checking if this fix resolves the issue reported in JDK-8332352 and found that this fix is causing change of behaviour in Ubuntu with KDE desktop environment.
To reproduce the issue follow the steps given in JDK-8332352. On selecting File menu, the popup window remains open until the mouse is pressed and closes as the mouse is released. The popup window is also not displayed below the File menu, it gets displayed with some offset, almost on the centre of the screen.
This issue is not observed in MacOS.

[karthikpandelu]

Screen recording of the above issue

video1963044341.mp4

[tsayao]

I think the mouse behavior is expected, since there is a pointer grab on popups.

But the location was wrong. It's fixed now.

[tsayao]

The linux build seems to be failing because the lack of gcc-13 package.

[jperedadnr]

@tsayao the Ubuntu runner uses now 24.0.4. Your branch just needs to be synced with head.

[tsayao]

@jperedadnr Thanks.

@karthikpandelu I tested the sample with the Debian 12 VM and it seems to work now. Would you re-test?

[karthikpandelu]

I can confirm that this now fixes the issue in Ubuntu with KDE desktop environment.
Both JDK-8332222 and JDK-8332352 are reporting the same issue. So I will close the latter as duplicate.

[tsayao]

Tests are ok.

[tsayao]

Can someone kindly review it?

[kevinrushforth]

Reviewers: @arapte @lukostyra

/reviewers 2

[openjdk]

@kevinrushforth
The total number of required reviews for this PR (including the jcheck configuration and the last /reviewers command) is now set to 2 (with at least 1 Reviewer, 1 Author).

[andy-goryachev-oracle]

Initial comments:

1. the description says this fixes two issues. do we have two JBS tickets? if so, please add the other ticket to this PR
2. the description in JDK-8332222 is insufficient: missing steps to reproduce, expected, and observed behavior.

Please update both PR and the ticket(s).

[andy-goryachev-oracle]

Question. I see different behavior between macOS and linux mint with the attached program (unmodified master branch).

On mac, the alert window is always positioned at the upper left corner, while on linux it is correctly placed at the center of the screen. Is this expected?

Also on mac, as I understand it, there is no "maximized" state, only full screen. So when the alert window comes up, the main window slides out of view and all we see is the black screen and alert widow at the upper left corner.

Unless we move the main window to another monitor. In that case I can see a number of differences:

1. main window in normal state, the alert comes up on a primary screen and not on the screen where the main window is located
2. when main window is "maximized" to full screen, both screens go into full screen mode, one (secondary) with the main window, the other (primary) with a black background. an alert pops up on the primary screen (i.e. other than the screen with the main window), but this time it is correctly positioned at the center of the primary screen.

I feel this behavior (on mac) is unexpected. Any ideas?

[andy-goryachev-oracle]

on linux mint, the positioning of the alert window in the case of two screens is the same as on mac, so it looks like it works "as designed".

[kevinrushforth]

If there are bugs on macOS, then I'd file a separate bug, since this bug is only about Linux behavior.

Also on mac, as I understand it, there is no "maximized" state, only full screen. So when the alert window comes up, the main window slides out of view and all we see is the black screen and alert widow at the upper left corner.

There is a maximized state on macOS. You can enter/exit maximized state programmatically, or by double-clicking on the title bar.

[andy-goryachev-oracle]

I don't see any difference with or without this fix on linux mint (I think it's running its own desktop env., different from KDE - how can I tell?).

[tsayao]

The issue 8332222 is KDE specific. When a MODAL or APPLICATION_MODAL window pops, all chindren (or all other windows in case of APPLICATION_MODAL are disabled. And part of de "disabling" is to not allow the window to be resized, so update_window_constraints "freezes" the window size. In the KDE case the window manager probably does not check if the window is maximized and ignores it as gnome does.

The fix is around the is_floating check - it checks if the window is "floating" on the screen and just constraint the sizes if it is.

[tsayao]

Initial comments:

1. the description says this fixes two issues. do we have two JBS tickets? if so, please add the other ticket to this PR
2. the description in JDK-8332222 is insufficient: missing steps to reproduce, expected, and observed behavior.

Please update both PR and the ticket(s).

@andy-goryachev-oracle Thanks for looking at Linux issues :)

1. No, the wrong behaviour of positioning was observed while trying to resolve the original issue on which this PR is linked. I don't know if someone reported it.

2. I think @jperedadnr opened it directly, so it didn't go through the user problem reporting process.

[andy-goryachev-oracle]

I've tested a bit more on linux mint (not a KDE desktop), see no ill effects.

There were a couple of warnings opening modal and regular windows, but the same warnings are present in the master branch.

For completeness sake, here they are:

Color picker -> custom color -> use?
(java:64981): Gtk-CRITICAL **: 15:36:07.237: gtk_window_resize: assertion 'width > 0' failed

tools -> FxTextArea Embedded in JFXPanel
(java:64981): Gdk-WARNING **: 15:37:06.136: XSetErrorHandler() called with a GDK error trap pushed. Don't do that.