Admin Left Menu Overlap

Seems to happen in Chrome and not Firefox.

Bump please.

Same problem here!

Me too. Seems like it’s a wordpress core bug.

same issue here. Just started today (or maybe I just noticed it today), but I updated to 4.3 over a week ago…

Happens on all my sites.

Collapse the menu then expand and it’s back to normal until clicking on menu item again.

Trying to teach my wife to use her new website and it’s VERY ANNOYING!!

Can confirm – have this issue on 4 different sites, running both WP 4.3 and also 4.2

Have also recently updated Chrome (Mac) this afternoon and didn’t notice this until after that update. Increasingly suspicious that the latest Chrome update is the culprit.

I noticed that visiting an edit list page with a long list of posts, that pushes below the fold, triggers the problem. It corrects itself when scrolling down, or when the window is re-sized.

I’d put bets down that Chrome changed the way window size is calculated in the 45.0.2454.85 build, but not sure just yet.

Quick update – this is indeed related to the latest Chrome 45 build. Being discussed in the Chrome help forums right now and someone has already developed a WP plugin to patch the issue as well.

Unfortunately I’m experiencing this in the newer Chrome v46 (beta) too.

I’m using this for the moment:

#adminmenu {
  transform: translateZ(0);
}

I put this in my functions file, and it fixed it (thanks Maderesponsively):

add_action('admin_head', 'admin_menu_fix');

function admin_menu_fix() {
  echo '<style>
    #adminmenu {
  		transform: translateZ(0);
		}
  </style>';
}

Fix for Chrome, without using any WordPress plugins or code:

– Go to chrome://flags/#disable-slimming-paint
– Enable the “Disable slimming paint” option.
– Ensure that the “Enable slimming paint” option below it is not turned on.
– Relaunch Chrome.

Turns out that “Slimming Paint” is a new permanent feature of Chrome.

If you’re using WP in a production environment with several admin users, I think the best solution is probably going to be to patch WP using the above CSS, and then wait for an update to WP core.

I know in my case this will be a little easier to manage than asking a dozen luddites to change Chrome flags until the next WP update…

Update: I just adapted and tested out the theme actions CSS patch above. Seems to work well, I put it in an answer on Stack Overflow for anyone interested. Only tested locally in Chrome 45 however..

I know in my case this will be a little easier to manage than asking a dozen luddites to change Chrome flags until the next WP update…

It is a bug in Chrome, and I expect Chrome will fix it eventually. No idea on a timeframe though.

Workarounds like the CSS code will do the job if you need immediate fixes and are not in a position to disable buggy parts of Chrome. I kinda doubt they’ll go into the WordPress core, but maybe. Depends on what the chrome team does and how the timeframes play out there. Something like this should be a priority fix, I would expect.

Are you certain the Chrome team considers this a bug though? It’s odd that they not only pushed this out as a stable release but it’s also in the next beta. Almost suspicious this is intentional.

The WP admin was using CSS transitions without declaring a graphics hardware acceleration method (transform: translate), kind of get the drift this is Chrome’s heavy handed way of forcing more sites to use 3d hardware acceleration

The Chrome team pushes out buggy stuff into stable all the time. Heck, they pushed out that HTTPS header thing into stable a while back, broke a heck of a lot of sites using a proxy for HTTPS implementation. Took them 2 weeks to get that fixed, and they actually knew about the problem when the code was still in canary. The fix simply didn’t get applied to the correct branches, and voila, it made it to stable before anybody noticed.

Screwing up the layout and then having it magically fix itself by forcing a redraw is clearly a bug. You can fix it any number of ways. Scrolling the page fixes it on most pages. Calling jQuery('#adminmenuwrap').hide().show(0); to force it to hide and show instantly fixes it as well. It’s just forcing a redraw.

The only thing that adding a transform: translateZ(0); does is to trigger a re-render of the specified element in the 3d engine. It’s not magic. It’s certainly not evil scheme Chrome has to make people use transform statements. It’s just causing the re-render and thus tricking the browser to follow a path that lacks the associated bug.