8269429: Linux: Only the last APPLICATION_MODAL window behaves correctly

[tsayao]

The PR approach is to set gtk_window_set_keep_above to true on APPLICATION_MODAL windows, so they will not stay behind non APPLICATION_MODAL windows.

This is passed on WindowStage.java:198 as a mask.

The weird thing is that _enterModal() is never called. This seems the right function to be called for APPLICATION_MODAL, as _enterModalWithWindow fits for WINDOW_MODAL.

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed

Issue

• JDK-8269429: Linux: Only the last APPLICATION_MODAL window behaves correctly

Reviewers

• Pankaj Bansal (@pankaj-bansal - Committer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jfx pull/551/head:pull/551
$ git checkout pull/551

Update a local copy of the PR:
$ git checkout pull/551
$ git pull https://git.openjdk.java.net/jfx pull/551/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 551

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jfx/pull/551.diff

[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.

[tsayao]

It's odd that glass Window.java defines enterModal but it seems to be never called. Modality is handled by calling setEnabled(false) on other windows.

I would refactor that some day :)

[mlbridge]

Webrevs

• 02: Full - Incremental (f7d2a9dd)
• 01: Full - Incremental (612a61ea)
• 00: Full (7b483449)

[tsayao]

It's working as expected:

If there's two APPLICATION_MODAL (*1) and (*2) and a WINDOW_MODAL (*3) as a child of the primary stage the order of the windows on the screen will be (*2) (*1) (*3).

Will run the tests and post here.

[kevinrushforth]

/reviewers 2

[openjdk]

@kevinrushforth
The number of required reviews for this PR is now set to 2 (with at least 1 of role reviewers).

[kevinrushforth]

I tried the test program attached to the JBS bug, and I'm not seeing the problem. Are there any special steps I need to take to see the bug? I also left a question about WINDOW_MODAL vs APPLICATION_MODAL windows.

Regarding the {enter/exit/is}Modal methods in Window.java, it looks like they stubs that are never called. Modality is handled by the toolkit using (as you found out) only the setEnabled method.

Finally, you have a typo in the title of both this PR and the JBS bug: corretly --> correctly

[tsayao]

I tried the test program attached to the JBS bug, and I'm not seeing the problem. Are there any special steps I need to take to see the bug? I also left a question about WINDOW_MODAL vs APPLICATION_MODAL windows.

Regarding the {enter/exit/is}Modal methods in Window.java, it looks like they stubs that are never called. Modality is handled by the toolkit using (as you found out) only the setEnabled method.

Finally, you have a typo in the title of both this PR and the JBS bug: corretly --> correctly

• Added steps to reproduce on JBS. Basically the window manager will let you click the window in the back (primary stage in the example) and the APPLICATION_MODAL will go behind it, still blocking events;
• Fixed the typo.

[tsayao]

[tsayao]

The first approach was to make the window not clickable or not "activable" when setEnabled(false) but I did not find a solution for that on Gdk or Gtk. Gtk has gtk_widget_set_sensitive but that did not work (probably only if using gtk signals). I did make other attempts with no success.

[pankaj-bansal]

I tried this on Ubuntu 20.04 and I see that the patch does solve the issue by bringing the Alert window above the primary window

[kevinrushforth]

This looks fine to me. I'll test it on a couple different systems. I left one comment inline.

[kevinrushforth]

I verified that this fixes the problem, but it also changes the behavior of APPLICATION_MODAL dialogs on Linux to be "Always on Top" -- not just on top of other application windows (which is fine), but on top of all other windows an application might create, which is not desirable as a default behavior. This also makes it behave differently than Mac or Windows.

I think we should look for a solution that doesn't rely on forcing a dialog to be on top of other (no app) windows.

[tsayao]

Will try to find a solution to disable events on disabled windows setEnable(false)

[tsayao]

This is also fixed by #581.