#26280 closed defect (bug) (fixed)
Z-index of the submenu not applied correctly in WP 3.8 Beta 1
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 3.8 | Priority: | low |
Severity: | normal | Version: | 3.8 |
Component: | Administration | Keywords: | has-patch |
Focuses: | ui | Cc: |
Description
I found a problem with the z-index of the main admin menu - when you insert an element into the body content of an admin page and set a z-index to that element greater than 2 (for example 10), the admin submenu goes below the element and its default z-index of 9999 is ignored.
You can easily replicate the problem with the browser developer tools, for example:
- Open the Dashboard page
- Use the developer tools to set z-index to the Welcome Panel element with class .welcome-panel:
.welcome-panel{ position:relative; z-index:10; }
- Hover the "Posts" menu item (or any submenu item that is close to the welcome panel) and you will see that the submenu is going below the panel:
Basically any element inserted to the content area with a z-index greater than 2 will be displayed on top of the submenu when a parent menu item is hovered.
After tracing the problem, I found that the #adminmenuwrap element that wraps the entire menu has a z-index of 2 set in the (wp-admin/css/wp-admin.css file):
.sticky-menu #adminmenuwrap { position: fixed; top: 32px; left: 0; z-index: 2; /* needs to be above .sticky-menu #wpwrap */ }
and as it is a parent of the submenu element that has a z-index of 9999:
#adminmenu .wp-submenu { padding: 7px 0 8px; z-index: 9999; }
the z-index of 9999 of the submenu element is ignored and the z-index of 2 that is set to the parent element is applied when the submenu is displayed.
I have also created a fiddle with simple isolated elements to illustrate the problem.
Attachments (1)
Change History (14)
#2
in reply to:
↑ 1
@
12 years ago
Replying to dd32:
We should revert to the z-indexes used in 3.7, which were probably around the 9999 mark as mentioned.
Yes, I just tested it with 3.7 and it looks fine with it
#5
@
12 years ago
- Owner set to iammattthomas
- Resolution set to fixed
- Status changed from new to closed
In 26442:
#6
@
12 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
I just noticed that this issue still exists, but with elements with z-index greater than 100.
I can see that now the #adminmenuwrap element z-index is set to 99 (wp-admin/css/wp-admin.css: http://core.trac.wordpress.org/browser/trunk/src/wp-admin/css/wp-admin.css#L1923):
.sticky-menu #adminmenuwrap { position: fixed; z-index: 99; /* Match the z-index of .wp-submenu to ensure flyout menus don't appear underneath main column elements */ }
and 99 is the z-index applied to the .wp-submenu element, instead of the 9999 set on the element here: http://core.trac.wordpress.org/browser/trunk/src/wp-admin/css/wp-admin.css#L1762
#adminmenu .wp-submenu, .folded #adminmenu a.wp-has-current-submenu:focus + .wp-submenu, .folded #adminmenu .wp-has-current-submenu .wp-submenu { padding: 7px 0 8px; z-index: 9999; }
So, any element inserted into the content with z-index of 100 or greater will be displayed over the submenu element.
#7
@
12 years ago
Confirmed that setting .sticky-menu #adminmenuwrap
to 9999
to match #adminmenu .wp-submenu
does fix it.
#9
@
12 years ago
- Priority changed from normal to low
We used 99 in 3.7. Is this a regression? Is there a screenshot or example that can be shown?
#10
@
12 years ago
- Resolution set to fixed
- Status changed from reopened to closed
Let's do a new ticket for this issue.
#11
@
12 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
Sorry to reopen the ticket, I just thought that there's no point in copying everything I said here in another ticket - if I really have to open a new ticket I will do it.
The issue doesn't exist in WP 3.7, as the #adminmenuwrap element doesn't have any specific z-index applied, I just inspected the code in 3.7 and I can see that the computed z-index of the #adminmenuwrap element is auto.
Right now the #adminmenuwrap has a z-index of 99 which overwrites the z-index of .wp-submenu of 9999 (as it is its parent), so the .wp-submenu element goes below elements that have z-index of 100 or greater.
As an example, as I mentioned above, just use the browser developer tools to set a z-index of 100 to the Welcome Panel:
.welcome-panel{ position:relative; z-index:100; }
and you will see how it goes over the submenu:
In fact there are no visual problems with WordPress by itself, but that would limit the plugin/theme developers to use elements with z-index greater than 99 - any element that has at least a z-index of 100 will get displayed over the submenu element.
#12
@
12 years ago
- Resolution set to fixed
- Status changed from reopened to closed
I requested a new ticket as this ticket was closed on a nearly-completed milestone (3.8), and any further issues here are going to be addressed in 3.8.1 at the earliest. I've created #26567 on your behalf. Thanks for the good info!
MP6 had to do crazy things with the z-indexes in order to combat core. I believe we reigned them in to 1 & 2 during the merge since we weren't seeing any issue.
We should revert to the z-indexes used in 3.7, which were probably around the 9999 mark as mentioned.