Last modified: 2014-11-20 16:59:48 UTC
Right now the z-index for .ve-ui-surface-overlay is set to 1000, which is way higher than pretty much anything else in MediaWiki. This makes it float above lots of things it shouldn't float above, like the header drop-down menu in the visual editor, the Echo notifications dropdown, etc. The z-index for the Echo notifications dropdown is 100 (so that it is higher than the close buttons in SiteNotices which are 99).
The VisualEditor's save dialog has a z-index of 3, so perhaps you'll want to use something like 2 for ve-ui-surface-overlay rather than 1000.
Created attachment 12545 [details] Blue overlay Is this screenshot related to this bug or another effect/issue?
(In reply to comment #0) > Right now the z-index for .ve-ui-surface-overlay is set to 1000, which is way > higher than pretty much anything else in MediaWiki. This makes it float above > lots of things it shouldn't float above, like the header drop-down menu in > the > visual editor, the Echo notifications dropdown, etc. The z-index for the Echo > notifications dropdown is 100 (so that it is higher than the close buttons in > SiteNotices which are 99). Yes, this was deliberate; you may recall the arms race with Echo where you kept breaking VE with your z-index changes for three weeks, hence this setting whilst we waited for Echo to stop changing. :-) (In reply to comment #2) > Created attachment 12545 [details] > Blue overlay > > Is this screenshot related to this bug or another effect/issue? That's specifically bug 49275, but yes, that is related to this. The "proper" solution to this is putting the entire save dialog in its own iframe (like all the dialogs we've created since the new dialog system was built), but it's too close to deployment to do major changes like that.
The z-index isn't too high, the reason the overlays are on top of the save dialog is because they are in a further relative subtree of the DOM. Whether it is z-index -999, 0 or 100000 won't matter. The actual issue described here is bug 49275. The overlay using z-index is a separate issue that is otherwise harmless. I'd recommend we: * Mark as invalid (z-index isn't a problem). * or; Turn this into a technical debt "clean up" reminder to get rid of the z-index (they're no longer needed afaik, because we moved overlays to be a proper relative subtree overlay instead of siblings with higher z-index). * or; Mark as duplicate of bug 49275.
Marking as tech-debt and pulling from beta per discussion.
Wasn't this fixed by Gerrit change #70572?
(In reply to Alex Monk from comment #6) > Wasn't this fixed by Gerrit change #70572? Yes.
