Opened 13 years ago

Closed 13 years ago

#198 closed defect (fixed)

modal child widgets go to background

Reported by: rudi Owned by:
Priority: major Milestone: Qt 4.7
Component: QtGui Version: 4.6.3
Severity: low Keywords:
Cc:

Description

Certain modal 3rd-level child widgets go to the background (i.e. behind the main window) when they should not. An example for this is in Arora browser:

1. Select "Tools/Options" from main menu
2. On the "Autofill" tab, click "Edit"
3.) Click on the Arora main window

What happens is, that the modal dialog "Form Passwords" will disappear behind the main window. Something similar can be observed with KDIFF3.

Change History (6)

comment:1 Changed 13 years ago by Silvan Scherrer

Rudi did you test with Qt 4.6.3? I added the 4.6.3 version now, so it can be selected.

comment:2 Changed 13 years ago by rudi

Version: 4.6.24.6.3

Yes.

comment:3 Changed 13 years ago by Dmitry A. Kuminov

I guess I see a similar problem with Qt Creator. Try to open the Session Manager dialog and then click the What is a Session? link below. You will notice that the main application goes on top while still remaining inactive (blocked by the Session Manager dialog).

Version 0, edited 13 years ago by Dmitry A. Kuminov (next)

comment:4 Changed 13 years ago by Dmitry A. Kuminov

Found the reason. We not always disable the blocked windows right. This is especially true when there is a bunch of modal windows created (and not necessarily visible). What happens is that the window to be disabled is first disabled and then gets accidentally re-enabled under some circumstances.

BTW, I had to do quite a lot of testing to see how this should behave. I found some inconsistencies, at least on Linux, where they block all the application when a window with WindowModal? windowModality() and NO parent is shown. While WindowModal? only means blocking parents and their siblings (as opposed to Application modal which is to block all regardless of whether it has a parent). I will not go this way on OS/2. (Windows seems to behave correctly).

comment:5 Changed 13 years ago by Dmitry A. Kuminov

I fixed the original issue in r936. The blocked windows are really blocked now, it should be impossible to put them in front of the modal windows they are blocked by, neither with the mouse, nor programmatically (e.g. from the Window List).

Note that there is one difference from the standard (expected) behavior: bringing the modal window in front does not pull the the window it blocks to the surface -- i.e. if both are obscured, attempting to activate either of them will reveal the modal window, but the blocked one will remain obscured. It's not easy to do it right since PM doesn't support window blocking in the way needed by Qt and Qt does not maintain its own global Z-Order list. I will try to solve that later.

comment:6 Changed 13 years ago by Dmitry A. Kuminov

Resolution: fixed
Status: newclosed

I implemented proper Z-order changes in r938. It was a bit tricky (it's always tricky to be smarter than PM wants you to be). But now it works quite well, in some aspects better than on Windows (e.g. activating the parent-less ApplicationModal? widget on Windows will not bring the widgets it blocks right behind it, if they are hidden, they will remain such -- on OS/2 this is not the case).

Also, under no circumstance there should be the case when the blocked (i.e. completely disabled) widget goes above the modal one -- this is what sometimes happens on Linux and which really annoys because you find yourself typing into a wrong window.

Enough for this defect. Feel free to create a new one if you find any problem with the new implementation.

Note: See TracTickets for help on using tickets.