jfx
jfx copied to clipboard
8332222: Linux Debian: Maximized stage shrinks when opening another stage
This fixes two bugs appointed on the JBS issue:
- Sometimes window was moving to the top left corner - seems to be a bug somewhere in
gdk_window_get_originwhen 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 theset_boundsfunction.
This seems to happen on newer versions of linux distros.
- Specific to KDE, in the case of the example provided, when an MODAL window pops, it calls
set_enabledfalseon 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
- [x] Change must not contain extraneous whitespace
- [x] 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
:wave: 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.
@tsayao This change now passes all automated pre-integration checks.
ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.
After integration, the commit message for the final commit will be:
8332222: Linux Debian: Maximized stage shrinks when opening another stage
Reviewed-by: jpereda, lkostyra
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.
At the time when this comment was updated there had been 7 new commits pushed to the master branch:
- 19d09e6c2e15683de1c69d0e841f32e337da2031: 8325445: [macOS] Colors are not displayed in sRGB color space
- f7ad5cdccb03162dc19fffb8eed570d4fbef490c: 8336389: Infinite loop occurs while resolving lookups
- 28e3ccc7331952b4d323941c8efc97509348b1e2: 8320232: Cells duplicated when table collapsed and expanded
- 0fa50cbbd9878ca7ec0e1bfcc5567bf52e3b8db2: 8337281: build.gradle assumes all modules are named "javafx.$project"
- 41de02023571d146f392de012a55011a5f87fc9d: 8336331: Doc: Clarification in AccessibleAttribute, AccessibleRole
- 686a396c6f1a5ee0733a69a046d2131f4649eca8: 8337228: Eclipse: missing dependencies in systemTests-test project
- cb7127d4b5e0c230adced8d24e7f695c519e9082: 8337229: Missing @Overrides in GlassSystemMenuShim
Please see this link for an up-to-date comparison between the source branch of this pull request and the master branch.
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.
➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.
Webrevs
- 04: Full - Incremental (b90968c0)
- 03: Full - Incremental (7f0115d0)
- 02: Full - Incremental (bb9a90b9)
- 01: Full - Incremental (7f6221a2)
- 00: Full (b3c7f407)
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.
Screen recording of the above issue
https://github.com/openjdk/jfx/assets/26969459/1a8cc7ce-5cd0-4562-85cb-01ea7f02b1de
I think the mouse behavior is expected, since there is a pointer grab on popups.
But the location was wrong. It's fixed now.
The linux build seems to be failing because the lack of gcc-13 package.
@tsayao the Ubuntu runner uses now 24.0.4. Your branch just needs to be synced with head.
@jperedadnr Thanks.
@karthikpandelu I tested the sample with the Debian 12 VM and it seems to work now. Would you re-test?
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.
Tests are ok.
Can someone kindly review it?
Reviewers: @arapte @lukostyra
/reviewers 2
@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).
Initial comments:
- the description says this fixes two issues. do we have two JBS tickets? if so, please add the other ticket to this PR
- the description in JDK-8332222 is insufficient: missing steps to reproduce, expected, and observed behavior.
Please update both PR and the ticket(s).
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:
- main window in normal state, the alert comes up on a primary screen and not on the screen where the main window is located
- 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?
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".
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.
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?).
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.
Initial comments:
- the description says this fixes two issues. do we have two JBS tickets? if so, please add the other ticket to this PR
- 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 :)
-
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.
-
I think @jperedadnr opened it directly, so it didn't go through the user problem reporting process.
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.
@tsayao This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!
I can confirm the bug happens on linux + x11 + awesomewm
This one: https://bugs.openjdk.org/browse/JDK-8332222
(I haven't tried the patches)
- Updated with master (so it picks up Robot on Wayland).
- Changed the scope to fix only the bug reported on JBS - will file another on for the other fix
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' failedtools -> FxTextArea Embedded in JFXPanel
(java:64981): Gdk-WARNING **: 15:37:06.136: XSetErrorHandler() called with a GDK error trap pushed. Don't do that.
The XSerErrorHandler() is a known conflict with Swing or anything else that also uses the error trap.
The problem depends on the Window Manager behavior, so it's not really DEBIAN specific. It affects Kwin and others as reported.
Is it ok to integrate? I got the e-mail saying so, but not really sure.
Is it ok to integrate? I got the e-mail saying so, but not really sure.
Yes. There are two approving reviews, and no outstanding comments or questions.
/integrate