Opened 9 years ago

Closed 8 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 9 years ago by diver

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 9 years ago by rudi

  • Version changed from 4.6.2 to 4.6.3

Yes.

comment:3 Changed 8 years ago by dmik

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. If you then click the main application window you will notice that it goes on top while still remaining inactive (blocked by the Session Manager dialog).

Last edited 8 years ago by dmik (previous) (diff)

comment:4 Changed 8 years ago by dmik

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 8 years ago by dmik

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 8 years ago by dmik

  • Resolution set to fixed
  • Status changed from new to closed

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.