Opened 14 years ago
Closed 12 years ago
#4527 closed bug (worksforme)
Stacked overlays cause odd behavior in WebKit-based browsers
Reported by: | Christopher | Owned by: | Christopher |
---|---|---|---|
Priority: | major | Milestone: | 1.9.0 |
Component: | ui.dialog | Version: | 1.7.1 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
When nesting dialogs in WebKit-based browsers and you close a dialog stacked on top of another, you get odd behavior: you can click on the buttons, but any <input>'s are not clickable and <select> elements will not open (but seem to register that they are being clicked on).
This could potentially be a browser issue, but maybe the z-indices being backwards has something to do with it. Mine become backwards because the generated dialog elements are only generated once and the z-index never changes, but the newly generated overlays are incremented, so it will eventually even become higher than the z-index of the topmost dialog, even though you can interact with the topmost dialog.
If you close all the dialogs and reopen them, then they will all become clickable again, even with backwards z-indices.
Tested in Safari 4 Beta and Google Chrome on Windows XP. Works as expected in Firefox 3.0.10.
Change History (5)
comment:1 Changed 14 years ago by
Milestone: | TBD → 1.8 |
---|
comment:2 Changed 14 years ago by
comment:3 Changed 13 years ago by
I can not reproduce the problem.(But I think I have seen a similar problem.)
I think #4545 says it is not possible to edit the input fields, nor to focus them in Firefox.
comment:4 Changed 12 years ago by
Owner: | set to Christopher |
---|---|
Status: | new → pending |
Could not replicate the issue in Chrome 10.0 or Safari 5.0.4 on OS X 10.6. Here's a JSBin test case:
comment:5 Changed 12 years ago by
Resolution: | → worksforme |
---|---|
Status: | pending → closed |
#4545 says the problem exists in Firefox as well, even though this ticket says it works in Firefox. I haven't tested any browsers yet.