Bug 270944

Of course, that was supposed to read "frequently stacks the windows in the wrong order".

I am not sure we can fix anything related to Firefox, as this is no KDE application. There is, however, a problem with KDE-only programs, as you mentioned, which use out-of-process daemons to requests passwords etc. Those should still be stacked according to their calling application.

Not sure if cross-process/-application modality is possible, but the stacking order should be fixable within KWin.

The bug may not be in KWin, but they know what needs to be changed below to get KWin behaving correctly.

For Firefox it should be fixable using the KWin scripting system.

For KDE apps it needs to be fixed in each single wrong behaving application. I don't think there is anything KWin can do about it.

Modal dialogs are permitted to show upon the _active_ desktop while the leader is on "not the active desktop" - that's ok and expectable.*
As soon as you move back to the desktop with the mainwindow, the dialog(s, all!) should (anything else would be a bug) move there as well.

It's perfectly ok for a modal dialog to be under another window (though appearing there is either due to a forced position by in the application -> client bug or a bad placing strategy/implementation -> our bug ;-)
This easily happens if the dialog appears while you're typing into another window which preserves the focus (thus the client doesn't raise - this would imply the request for a "always raise new clients" option)
Again: when you move to the desktop with the main widow, the modal dialog should not only move there as well, but of course also always keep above the main window.

If a client spawns multiple modal dialogs it actually has to restack them itself, since afaik there's no hint about which is the "active" one (this is a client internal detail) but in general this sounds like bad design: modality indicates that the client is blocked (for the hard requirement to await input to sync a state or whatever) - it should not be able to spawn other dialogs (for logical reasons)
If it can this indicates that the dialogs are peers - they should share the same eventloop so that you can interact with either but not the main window (no idea whether gtk has built-in support for this. As for Qt one would likely just open the dialogs asynchronously, disbale the main window and bind the dialogs close signals to a checker slot that enables the mainwindow when all relevant dialogs are gone - could be encapsulated in a kdialoggroup ;-)

*A modal dialog likely means that the application is halted and waits for input and you don't want to come back half an hour later to figure that nothing happened.

I'd like to join this issue. This is my following use case:

Desktop 1) Internet Desktop - Firefox maximized
Desktop 2) Eclipse Desktop - Eclipse maximized

Usually when I open Eclipse, I switch to the first desktop (mostly because I dont enjoy watching progress bars) and browse while I wait for eclipse to load. In my eclipse installation I receive a pop up from the Eclipse key manager to enter my password. This is a modal dialog. 

Now usually this dialog happens to display on the first desktop and usually under firefox. When I go back to eclipse, the application seems to be unresponsive, but it is really just waiting on the modal dialog to close. But that one is hidden on desktop 1. Is there anything I can do to walk around the issue?

Generally sounds like an eclipse bug
-> please attach dumps of "xprop" on the modal dialog as well as on the eclipse main window
(the expected behavior -on a somewhat recent KDE, like 4.5 or 4.6- would be to move the dialog to the main windows desktop as soon as you move there, but therefore the relation between the two windows must be propagated - eclipse uses swing or AWT, does it?)

As a workaround, you can force the dialog to
a) initially appear or even always remain on desktop #1
b) initially be set or even always remain "stay on top" (will appear above FF)
c) force the focus stealing protection level of the dialog to "none" (should get mapped on top AND receive the keyboard focus while FF is considered to be 'in use")

-> run "kcmshell4 kwinrules"

Hey thanks for the response. Will do that.

Eclipse unfortunately runs on SWT which maps api calls to GTK. Maybe that is the issue? (e.g. this being a GTK window)

No, Gtk+ usually supports the transient hint, but it must of course be set, what gtk will (likely) just do when you create a modal dialog. SWT probably implements the modality in java and just creates a general Gtk+ dialog and does not set the transient hints, resulting in false behavior.

If you're using compositing, the "dim dialog parent" effect will visually reflect the WM's knowledge about this relation. If the eclipse main window is not dimmed while the dialog is present, it's not considered to be a (modal) relation.
Details about the issues source can only be found in the properties.

I will load them up asap.

I think the dialog gets dimmed, but only then when the dialog is on the same workspace. But let me double check

Created attachment 68141 [details]
xprop of the dialog

Created attachment 68142 [details]
xprop of dialog which is spawned on second desktop

Created attachment 68143 [details]
xprop of main window

Created attachment 68144 [details]
xprob of window when the dialog spawns on other desktop

Created attachment 68145 [details]
window dialog screen

please see attachment. The attachment with suffix broken are cases when the dialog spawned on the other desktop

That's really strange - the working dialog has a sufficient WM_TRANSIENT_FOR hint while the other one does not.
Also the non working dialog is of type _NET_WM_WINDOW_TYPE_NORMAL instead of _NET_WM_WINDOW_TYPE_DIALOG

Looks like the clients tries to be extra smart by avoiding that relation in case the main window is unmapped/on another desktop.

In case you're using compositing and do NOT have "kcmshell4 kwincompositing", 3rd tab  "Keep window thumbnails" as "Never" it wouldn't be for the mapping state but the client would actually check the desktop property and "break" it's settings in this case (what is wrong - the relation is only a hint and can be set regardless)

Created attachment 68152 [details]
Setting screen

I am not quite sure I understand the last comment. This might very well be an eclipse / swt bug. Other modal dialogs seem to behave in a correct way (e.g. I get a notification in docky, and the dialog stays on the workspace).

Let me talk to the eclipse guys. On another note, ss there some way I can force the parent dialog using the windows rules?

compositing is what makes windows translucent, paints shadows and fancy animations when showing/hiding windows. if it's active (cannot be seen on thescrenshot) windows on other desktops are not really taken off screen (with your setup)

it's for quite sure an issue of swt/eclipse. rather not gtk an for sure not of the wm (kwin in this case)

it's not possible to define a treansient relation via the rules, most importantly because the parameter (the id of the main window) is not static but will be assigned a random value everytime it's recreated. one could probably add a rule that says "make this window modal and search for the likely transient, but that's rather wonky, can have ugly false positives and serves nearly no usecase (because if some client doesn't set this hint, it will usualy not set the hints to estimate a possible relation)

it might be possible to achieve that by upcoming scripting support but the only correct way is to fix the actual bug in this case (eclipse is still maintained and this issue will in one way or another hit every desktop system)

Yes, composition is enabled. It is not a gtk bug, as other modal dialogs behave correctly. This dialog is contributed, so that might be part of the issue. Ill have a chat with the eclipse team. 

The eclipse guys use primarily windows and on that platform it is not much of an issue, since windows does not have virtual desktops.

Did you meanwhile get any feedback from the eclipse developers?
Is this still an issue?

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!