#16152 closed defect (fixed)
Dialog: calling show() while hide() in progress confuses DialogLevelManager --- Remaining overlay blocks page
| Reported by: | Paul Christopher | Owned by: | bill |
|---|---|---|---|
| Priority: | undecided | Milestone: | 1.6.3 |
| Component: | Dijit | Version: | 1.8.0 |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: |
Description
Description
Multiple calls to dialog.show and dialog.hide confuse the DialogLevelManager. The last call in the chain of dialog.hide does hide the dialog, however the underlay remains on the screen and makes the whole page not usable for the user anymore since the overlay prevents any interactions with the mouse.
Steps to reproduce the issue
- In Dialog.js add some console.logs to the show/hide method of the DialogLevelManager. Especially dump the dialogstack ds each them. Do also add console.logs to _DialogBase.show/hide and check this.open there.
- Run the attached test case
Discussion
The underlay is not closed because the dialogstack is full with new instances of the displayed dialog - although the dialog isn't displayed anymore. Don't know why this happens. "this.open" in _DialogBase.show seems not to be recognized (is "false")and each time dialog.show is called, a new dialog is opened?
This is a reduced real life example in which we used an Ajax loader based on dijit/Dialog. We changed the application code now to prevent those multiple calls. Nevertheless I wanted to share the test case here. Maybe this edge case also needs some corrections to Dialog.js?
Attachments (2)
Change History (13)
Changed 9 years ago by
| Attachment: | testDialog.html added |
|---|
comment:1 Changed 9 years ago by
comment:2 Changed 9 years ago by
To fix the hide order issue of dialog and underlay: Maybe it is enough to give DialogUnderlay._singleton.hide(); (line 571) a setTimeout with manager.defaultDuration and if the dialog is shown again just a clearTimeout?
Changed 9 years ago by
| Attachment: | PatchDialog1-8-0[CLA].diff added |
|---|
comment:3 Changed 9 years ago by
Added a proposal for a patch but don't know whether this really fits into the architecture.
comment:4 Changed 9 years ago by
| Milestone: | tbd → 1.9 |
|---|---|
| Status: | new → assigned |
| Summary: | dijit/Dialog: Multiple show/hide calls confuse DialogLevelManager --- Remaining overlay blocks page → Dialog: calling show() while hide() in progress confuses DialogLevelManager --- Remaining overlay blocks page |
I see, thanks for the test case. We do have some tests in dijit/tests/Dialog.html, such as "concurrent hide show", where things work correctly, but obviously not in the case you showed.
As you said, the DialogLevelManager.hide(this) call comes at the end of the fade-out. And Dialog.show() cancels an in-progress Dialog.hide(). So when the Dialog.hide() is interrupted by a Dialog.show(), DialogLevelManager.hide(this) never gets called. But Dialog.show() still calls DialogLevelManager.show(this, this.underlayAttrs) again, hence the imbalance.
I think rather than calling DialogLevelManager.hide(this) early like in your patch, I'll modify Dialog.show() to act differently when it's cancelling an in-progress hide.
comment:6 Changed 7 years ago by
Team,
We are still on Dojo 1.6 and facing same issue, how can I get the fix for same issue for Dojo 1.6?
Thanks in advance.
comment:11 Changed 7 years ago by
| Milestone: | 1.9 → 1.6.3 |
|---|
The problem seems to be the call of DialogLevelManager.hide(this) (dijit/Dialog.js line 432) inside the onEnd callback of the fx.fadeOut. If DialogLevelManager.hide(this) is called immediately after this._set("open", false) (line 449) (and not after the fad out has finished), there would be no problems with the given test case. On the other hand, this would change a lot: The underlay would be hidden before the dialog is hidden, and that's not really what we want...