Bug #6379
closedWDialog is sometimes created behind an existing one
0%
Description
Widgets of class WDialog are usually created in front of existing dialogs as expected, but sometimes, it fails and the new dialog is open behind an existing one.
The way to replicate it seems to be: open an asynchronous dialog (d1), then click on a button that opens another asynchronous dialog (d2). In the d2 dialog, click on a button that closes it and destroys it. Then on the d1 dialog, click on the button that opens the d2 dialog again. The d2 dialog will appear behind d1.
It might not be the only way to replicate it. The problem can be partially avoided fixed by calling the d2 dialog's raiseToFront() method whenever it's created, but it doesn't seem to work on all browsers.
Files
Updated by Roel Standaert almost 6 years ago
- File issue_6379.cpp issue_6379.cpp added
- Status changed from New to Feedback
I tried to reproduce this with the latest master, but it appears to be working properly. Maybe I didn't completely understand your issue. I attached the test I used.
Updated by Ján Dugáček almost 6 years ago
I can replicate it on the latest version. However, I found that I have missed out one crucial step in the replication process. Writing it again:
- open an asynchronous parentless dialog (d1)
- move d1 so that the a newly opened dialog would partially overlap it, but its clickable contents would not be obstructed
- click on a button that opens another asynchronous parentless dialog (d2)
- (added) click on an empty place on d1 to make it raise to above d2
- in the d2 dialog, click on a button that closes it and destroys it
- in the d1 dialog, click on the button that opens the d2 dialog again
- d2 dialog will appear behind d1
Updated by Saif Rehman almost 6 years ago
Is this related to my issue: https://redmine.emweb.be/issues/6219 ?
Updated by Ján Dugáček almost 6 years ago
So I have created a test case where it can be replicated. It's at: https://pastebin.com/Mu0YmtuV
The progression is as I described, open one dialog, move it slightly to the left, open another dialog, click on the first dialog, close the other dialog, open a new dialog and the dialog will appear behind the first one.
Updated by Roel Standaert over 5 years ago
- Target version changed from 4.0.4 to 4.0.5
Updated by Roel Standaert over 5 years ago
- Status changed from Feedback to InProgress
- Assignee set to Roel Standaert
I see what's happening here:
- A new dialog (A) is created and given z-index 0 + 100 = 100
- Another dialog (B) is created, given z-index 100 + 100 = 200 (new dialogs get a higher z-index)
- Dialog A is brought to front, the associated JavaScript code adds 1 to the highest z-index of the other popups, yielding z-index = max(100, 200) + 1 = 201, however the server is unaware of this new z-index
- Dialog B is closed
- A new dialog © is created and given z-index 100 + 100 = 200, because as far as the server is concerned, the z-index of dialog A is still 100 (while it is actually 201)
- Result: dialog C is shown under dialog A instead of on top of it
So now I'll have to see what the best way would be to fix this...
Updated by Roel Standaert over 5 years ago
- Status changed from InProgress to Resolved
Updated by Roel Standaert over 5 years ago
- Status changed from Resolved to Closed