Chrome 45 incorrectly renders admin menu

[atomicjack]

If you go to a Settings page and hover over the sidebar admin menu a bit, the items begin to break a little, like so:

This was tested on Chrome: 45.0.2454.15 beta (64-bit)

[SergeyBiryukov]

Could not reproduce on a clean install with Chrome 44.0.2403.125 (latest stable at the moment).

[atomicjack]

Replying to SergeyBiryukov:

Could not reproduce on a clean install with Chrome 44.0.2403.125 (latest stable at the moment).

Very strange. I'm definitely noticing it on a clean install.

I think you have to hover over all the items a bit, eventually it messes up.

[atomicjack]

Apparently my keyboard closed this ticket by mistake - opened.

[dmchale]

The latest stable build of Chrome is working fine. According to the ​Developer Blog post from just today, version 44.0.2403.125 (Platform version: 7077.111.0) is the latest public release. Your ticket reports an error with a beta build of Chrome, 45.0.2454.15 beta.

Unfortunately I don't have an environment where I can safely install/test the beta build. But I would wager that whatever is manifesting will likely be fixed before public release.

[ocean90]

This looks like an rendering issue in Chrome. I found something similar with the mobile menu in Chrome version 44.0.2403.125 (64-bit) see ​https://cloudup.com/clSycY4hEYQ. But I could reproduce this issue in 4.2 and 4.1 too.

[atomicjack]

Hi @ocean90,

I'm also noticing it in 4.2.3 and 4.2.4.

So it seems to be an issue with Chrome v44 and v45, which means this needs to be looked into, as it is getting past Chrome's bug reporting system and even into actual releases. So it could be either a WordPress or Chrome issue; my concern is, it makes it quite difficult to navigate the admin area.

[ocean90]

#33274 was marked as a duplicate.

[nicola.peluchetti]

I can confirm this on 4.2.4 and 4.2.3 Chrome 64bit / Version 45.0.2454.26 beta-m (64-bit) / Windows 7

[netweb]

This is now fixed in the dev and canary channels

Previously confirmed in Chrome Version 45.0.2454.15 dev (64-bit)

Fixed in Chrome to Version 46.0.2471.2 dev (64-bit) and Version 46.0.2475.0 canary (64-bit)

[netweb]

Replying to netweb:

This is now fixed in the dev and canary channels

Previously confirmed in Chrome Version 45.0.2454.15 dev (64-bit)

Fixed in Chrome to Version 46.0.2471.2 dev (64-bit) and Version 46.0.2475.0 canary (64-bit)

Looks like I spoke to soon, confirming still broken in both 46.0.2471.2 and 46.0.2475.0 :(

[pier25]

I updated Chrome Canary to 46.0.2478.0 (64-bit) and the error is gone for 4.2.4

What's strange is that Opera does not present the error even when it's also based on blink. Maybe they are a few versions behind.

On the screenshot there are multiple browsers side to side.

Chrome
Chrone Canary (before updating)
Firefox
Safari
Opera

​http://imgur.com/Qb8zzHE

[pier25]

Well actually it seem a bit random. If I refresh the dashboard on Chrome Canary half of the times the bug appears...

You can see it in action here.

​https://youtu.be/j8C9PdNitJs

[atomicjack]

Replying to pier25:

Well actually it seem a bit random. If I refresh the dashboard on Chrome Canary half of the times the bug appears...

You can see it in action here.

​https://youtu.be/j8C9PdNitJs

It always happens for me - you just have to move your mouse around the menus a bit, particularly the drop-downs.

[atomicjack]

Still an issue in 45.0.2454.26 beta.

[atomicjack]

Present in 45.0.2454.37 beta.

[upct]

Same problem here with Chrome Version 45.0.2454.37 beta-m

[obenland]

#33445 was marked as a duplicate.

[KoenRijpstra]

Looks like the problem is fixed in version 46.0.2490.4 dev (64-bit)

[pross]

Glitch is reproducible on released stable version of chrome 45.0.2454.85 64bit osx. Tested with 4.3 and latest trunk.

[ryan]

I too could reproduce with 45.0.2454.85 64bit osx. Clearing browsing data did not fix the probem.

[ryan]

Related chat: ​https://wordpress.slack.com/archives/core/p1441149322002218

[SergeyBiryukov]

#33666 was marked as a duplicate.

[joefletcher]

There's a Chrome product forum post here:
​https://productforums.google.com/forum/#!msg/chrome/_T7hln9XMzE/ZcU5Zg1R9CQJ

[jcastaneda]

One way of somewhat fixing I found was collapsing the menu.

[joefletcher]

@jcastaneda, there's a temporary workaround plugin that will auto close/open the sidebar. Gets the job done, but I'll be using Firefox in the meantime. ​https://github.com/raffjones/chrome-admin-menu-fix

[Otto42]

Doing a jQuery('#adminmenuwrap').hide().show(0); on the window.load seems to cause Chrome to rerender the menu correctly.

In other words, this attached to admin_head seems to do the job:

<script type='text/javascript'>jQuery(window).load(function(){jQuery('#adminmenuwrap').hide().show(0);});</script>

[knutsp]

#33445 was marked as a duplicate.

[bobcatou]

Breaks in Chrome Version 45.0.2454.85 (64-bit) too. It started to happen this morning. I also had Chrome asking me if I wanted the page translated. It thought my admin screen was in Japanese. It was in English.

[elementpz]

#adminmenu {
  transform: translateZ(0);
}

Here you go :)

[atomicjack]

For relevancy purposes, Chromium is tracking the issue and seems to have found the problem code: ​https://code.google.com/p/chromium/issues/detail?id=509179

Issue also affects the stable build of Chrome now.

[kalich5]

I have same problem.

[igmoweb]

Same issue for me in all my sites.

Chrome 45.0.2454.85 (64-bit)
OS X Yosemite 10.10.4 (14E46)

[raffjones]

You can fix this with CSS:

function chromefix_admin_init()
{
  if ( strpos( $_SERVER['HTTP_USER_AGENT'], 'Chrome' ) !== false ) 
  {
    add_action( 'admin_print_styles', 'chromefix_print_css' );
  }
}

function chromefix_print_css()
{ 
?>
  <style type="text/css" media="screen">
    #adminmenu { 
      transform: translateZ(0);
    }
  </style>
<?php
}

add_action( 'admin_init', 'chromefix_admin_init' );

Add that to your theme's functions.php file and it will sort the problem.

If you just want a plugin to do it: ​https://github.com/raffjones/chrome-admin-menu-fix

[atomicjack]

Think this should be pushed into 4.3.1 until Chrome fixes it? It gives a really bad experience and makes using the admin menu a chore.

[raffjones]

Replying to atomicjack:

Think this should be pushed into 4.3.1 until Chrome fixes it? It gives a really bad experience and makes using the admin menu a chore.

I agree. It's starting to hit a lot of users, and as the CSS fix is so simple, it would be ideal to get it into the core - especially as it will have no adverse effects once the issue is resolved.

[netweb]

Replying to atomicjack:

For relevancy purposes, Chromium is tracking the issue and seems to have found the problem code: ​https://code.google.com/p/chromium/issues/detail?id=509179

Issue also affects the stable build of Chrome now.

I've just added a quick comment to the above chromium issue tracker linking back to this ticket

[Otto42]

If you're going to use css like that, probably better to use wp_add_inline_style.

add_action('admin_enqueue_scripts', 'chrome_fix');
function chrome_fix() {
	if ( strpos( $_SERVER['HTTP_USER_AGENT'], 'Chrome' ) !== false )
		wp_add_inline_style( 'wp-admin', '#adminmenu { transform: translateZ(0); }' );
}

[raffjones]

Yes, that's better - nice work. Seems like a solid fix for the time being.

[Otto42]

An alternative solution that works for people who don't want to mess with their WordPress installs:

In Chrome, go to chrome://flags/#disable-slimming-paint

Enable the "disable slimming paint" setting and ensure that the "enable-slimming-paint" setting immediately below it is not turned on.

Chrome will need to Relaunch to save the setting. Once you have done so, the bug is gone.

[upct]

Thanks @Otto42 ! This solution work like a charm, perfect when you have more than 30 WP installations !

Thanks again !

[swissspidy]

#33708 was marked as a duplicate.

[Howdy_McGee]

Replying to Otto42:

In Chrome, go to chrome://flags/#disable-slimming-paint

Enable the "disable slimming paint" setting and ensure that the "enable-slimming-paint" setting immediately below it is not turned on.

This works but why does it work?

[Otto42]

Replying to Howdy_McGee:

This works but why does it work?

Because that's where the bug is, whatever it is.

A user on the chromium ticket did a bisect and found the problem at a specific commit to the Chrome code. That commit was "Enable Slimming Paint by default in Chromium and Blink"

Comment 17: ​https://code.google.com/p/chromium/issues/detail?id=509179#c17

So, disabling the new Slimming Paint code will fix the issue. For now. Whatever the bug in Chrome is, it's in Slimming Paint somewhere.

[zenjiweb]

I inspected the admin navigation menu and it immediately struck me that even without this chrome bug, I'd consider it a candidate for applying hardware acceleration regardless.

So out of curiosity I tested enabling / disabling the transform: translateZ(0); patch using Firefox Mac (since chrome is fubar) and sure enough applying GPU acceleration seems to remove some noticeable lag time on menu hover reveal / hide.

A patch to WP admin that applies CSS transform to the menu could be a positive improvement with benefit beyond this particular chrome issue. Just wanted to put that thought out there.

[ideasatrandom]

issue-33199-add-css-transform

[ideasatrandom]

Attached a patch file issue-33199-add-css-transform.patch ... Added transform: translateZ(0); to the admin-menu.css in development version (4.4-alpha-33636-src) ... Fixed the issue for me ... Would the change in my patch be the appropriate place to add the transform property? (This is my first time submitting a patch) ... Tried out the site using an older browser, Windows 7 + IE 9 and nothing broke ... I can test out other combinations if it would help out.

[SergeyBiryukov]

#33718 was marked as a duplicate.

[atomicjack]

The Chrome bug has now been assigned, however I believe they've marked it for v47 release, as 45 is already in stable and 46 is pushing through. Definitely need to get this patched up

[atomicjack]

Replying to ideasatrandom:

Attached a patch file issue-33199-add-css-transform.patch ... Added transform: translateZ(0); to the admin-menu.css in development version (4.4-alpha-33636-src) ... Fixed the issue for me ... Would the change in my patch be the appropriate place to add the transform property? (This is my first time submitting a patch) ... Tried out the site using an older browser, Windows 7 + IE 9 and nothing broke ... I can test out other combinations if it would help out.

I'd say your patch will do just fine.

Let's get this into core... :)

[Design Wave]

Replying to atomicjack:

Let's get this into core... :)

Here's a good answer (with demo), why you should not do this - ​http://stackoverflow.com/a/10814448

Obviously, it's a Chromium problem, not a WordPress one.
As @pier25 mentioned, other browsers show it perfectly fine.

​http://imgur.com/Qb8zzHE

[atomicjack]

Replying to Design Wave:

Replying to atomicjack:

Let's get this into core... :)

Here's a good answer (with demo), why you should not do this - ​http://stackoverflow.com/a/10814448

Obviously, it's a Chromium problem, not a WordPress one.
As @pier25 mentioned, other browsers show it perfectly fine.

​http://imgur.com/Qb8zzHE

We're aware it is a Chromium issue, however, no-one knows how long it is going to take to fix, it took them a very long time to even get to the ticket, and they haven't found the core problem yet. On top of that, I believe someone said they expect it for v47, which is awhile away yet.

For a temporary fix - and, people have used this CSS adjustment, without issue, what's the actual problem it is going to cause if it is limited to just the sidebar of the wp-admin?

[johnjamesjacoby]

Replying to atomicjack:

what's the actual problem it is going to cause if it is limited to just the sidebar of the wp-admin?

Good question. Here's what I can think of:

• To start, z-indexes should be tested (in places like the customizer and media modals, off the top of my head) to ensure menu sub-navigation doesn't overlap them.
• Then, the scroll-spy style movement of the menu needs to be confirmed that it's still working, and working smoothly.
• Next, browser testing should confirm this fix doesn't break something else (I don't think that it will, in my experience with this.)
• Finally, bundled scripts that create pop-ups or modals (jQuery UI Datepicker, et all) should be tested to confirm they don't react differently to this new rendering, painting, & positioning.

[atomicjack]

Replying to johnjamesjacoby:

Replying to atomicjack:

what's the actual problem it is going to cause if it is limited to just the sidebar of the wp-admin?

Good question. Here's what I can think of:

• To start, z-indexes should be tested (in places like the customizer and media modals, off the top of my head) to ensure menu sub-navigation doesn't overlap them.
• Then, the scroll-spy style movement of the menu needs to be confirmed that it's still working, and working smoothly.
• Next, browser testing should confirm this fix doesn't break something else (I don't think that it will, in my experience with this.)
• Finally, bundled scripts that create pop-ups or modals (jQuery UI Datepicker, et all) should be tested to confirm they don't react differently to this new rendering, painting, & positioning.

Thanks for pointing out specific areas of concern.

I'll test some of those now and report back shortly.

[johnjamesjacoby]

Replying to atomicjack:

Thanks for pointing out specific areas of concern.

I'll test some of those now and report back shortly.

Thank you for jumping in and testing these out. If there are any differences (and if you are able) attaching before/after screenshots to highlight any breakage or differences will help others avoid duplicating your efforts.

[atomicjack]

Tests:

• Customizer and Media modals display and work as expected - Chrome 46. - attached screenshot.
• Menu collapsing into responsive-view, works as expected - Chrome 46.

[atomicjack]

Media Modal displays correctly with this CSS change

[atomicjack]

Dropdowns display correctly

[atomicjack]

Menu Collapsed displays correctly

[atomicjack]

Menu Uncollapsed displays correctly

[atomicjack]

Responsiveness of the menu works as expected

[atomicjack]

The only thing I can't test, is the jQuery UI Datepicker. I've no idea how for that, as I don't have it used anywhere.

[zenjiweb]

In case this helps, here are some environments where I’d normally expect CSS transform bugs to be lurking

Older Browsers:

• Webkit browsers circa maybe 2013 or older (esp Android browser)
• IE9

Devices w/ crummy graphics hardware:

• Android devices - particularly older or cheaper models
• Cheap netbooks
• Older laptops

In early implementations of transforms, if I recall some of the issues wouldn't surface immediately. They would take a bit of user activity to reproduce.

I don’t think WP even officially supports most of the stuff in here? Thought maybe worth noting

[atomicjack]

Replying to zenjiweb:

In case this helps, here are some environments where I’d normally expect CSS transform bugs to be lurking

Older Browsers:

• Webkit browsers circa maybe 2013 or older (esp Android browser)
• IE9

Devices w/ crummy graphics hardware:

• Android devices - particularly older or cheaper models
• Cheap netbooks
• Older laptops

In early implementations of transforms, if I recall some of the issues wouldn't surface immediately. They would take a bit of user activity to reproduce.

I don’t think WP even officially supports most of the stuff in here? Thought maybe worth noting

Although it is generally frowned-upon, I feel this is a situation where 'browser detection' may be accepted, temporarily.

Detect if the browser is Chrome and apply the transform.

However - if other browsers don't cause an issue, then i see no problem with keeping the transform without browser detection.

[danieltj]

Experienced this myself, although it happened on my desktop and not on my laptop. Only started happening last night as well. It worked fine on everything on certain pages like the list of posts but started acting up on the Dashboard.

[Design Wave]

adminmenu CSS transform fix

[Design Wave]

For a moment I also thought this CSS fix is a solution. Till I resized Chrome window to 780px width and tried to pick Settings item from the Admin Menu.

[zenjiweb]

Replying to atomicjack:

Detect if the browser is Chrome and apply the transform.

Ah but one of the older webkit browsers with issues was in fact Chrome. Honestly I don't think this type of transform use would make for any showstopper issues in the environments I listed, but if doing thorough QA those are environments I'd look at.

Re: @Design Wave issue at 780px width.

I was able to reproduce this. But.. I was also able to reproduce in Firefox with the CSS transform disabled.

[Design Wave]

Replying to zenjiweb:

I was able to reproduce this. But.. I was also able to reproduce in Firefox with the CSS transform disabled.

Yes, that's true. Latest versions of Opera and Firefox display it the same way.
Funny, but only my old Safari shows uncollapsed menu as it should be - ​http://cl.ly/cs2d

[SergeyBiryukov]

#33733 was marked as a duplicate.

[Marcoevich]

#33739 was marked as a duplicate.

[Clorith]

Current nightly 4.4-alpha-33904 is actually showing the menu issues even with slimming paint disabled on chrome 45.0.2454.85

[ideasatrandom]

Settings menu still broken without CSS transform patch

[ideasatrandom]

Replying to Design Wave:

For a moment I also thought this CSS fix is a solution. Till I resized Chrome window to 780px width and tried to pick Settings item from the Admin Menu.

Settings menu still broken without CSS transform patch:

Tried resizing Chome to 780px using a WP install without the CSS patch in this ticket …
It still broke the side menu when trying to access the Settings menu …
Looks like a new layout bug that might need a Trac ticket?

[crzyhrse]

I just noticed something, in case it is helpful...

I have about a dozen WP sites in one reseller account. In about half of them that have really long dashboards (lots of plugins and CPTs) I cannot reproduce this issue at all. On the sites that have short dashboards (not developed very far or whatever) the issue is definitely there without exception.

So on a dev site with a long dashboard I deactivated all of the plugins/CPTs to shorten the dashboard, and with that, the issue was immediately reproducible. I then reactivated plugins/CPTs and again could not reproduce the issue in the returned long dashboard.

I am using Chrome.

Edit: Otto's chrome://flags/#disable-slimming-paint solution seems to have fixed it in the meantime.

[atomicjack]

#33761 was marked as a duplicate.

[atomicjack]

#33762 was marked as a duplicate.

[swissspidy]

#33765 was marked as a duplicate.

[vaschops]

I enable the 'Disable Slimming Paint' ... which definitely worked for me.
Although I am not sure what repercussions this might have.

chrome://flags/#disable-slimming-paint

[ocean90]

#33781 was marked as a duplicate.

[myrecipepicks]

Replying to atomicjack:

If you go to a Settings page and hover over the sidebar admin menu a bit, the items begin to break a little, like so:

This was tested on Chrome: 45.0.2454.15 beta (64-bit)

This is also confirmed when filtering for different post statuses, changing post statuses, and pretty much doing anything in the admin dashboard. Pretty much makes WP unusable at the moment.

[pento]

#33784 was marked as a duplicate.

[atomicjack]

A fix is now in the works, and the bug mostly located, however, there's no ETA, and from the way it's worded, looks to be a slow one.

​https://code.google.com/p/chromium/issues/detail?id=509179#c60

[swissspidy]

#33788 was marked as a duplicate.

[sksdev]

Replying to swissspidy:

#33788 was marked as a duplicate.

Thanks for confirmation

[inderpreet99]

It may help if everyone involved here can star the chromium issue, which sort of votes it up in their work queue.

​https://code.google.com/p/chromium/issues/detail?id=509179

[miqrogroove]

Replying to inderpreet99:

It may help if everyone involved here can star the chromium issue, which sort of votes it up in their work queue.

​https://code.google.com/p/chromium/issues/detail?id=509179

I will give it a star. Did we confirm this is a Chrome bug and not a WP bug?

[atomicjack]

Replying to miqrogroove:

Replying to inderpreet99:

It may help if everyone involved here can star the chromium issue, which sort of votes it up in their work queue.

​https://code.google.com/p/chromium/issues/detail?id=509179

I will give it a star. Did we confirm this is a Chrome bug and not a WP bug?

Yes, it is a Chrome bug with its new rendering engine. Blink>Slimming Paint.

Scheduled fix: v46 rather than v47 now.

[SergeyBiryukov]

#33792 was marked as a duplicate.

[Otto42]

Chromium bugtracker reports a fix will be in Canary tonight, probably not in Stable until Chrome 46.

​https://code.google.com/p/chromium/issues/detail?id=509179#c71

[inderpreet99]

Thanks to continued effort by WordPress users on the ​chromium issue page, it looks like we'll see this get fixed in current stable Chrome 45 and upcoming beta Chrome 46. No need to patch up WordPress! :)

[azaozz]

Not setting the menu to position: fixed; avoids this bug. We can add that in 4.3.1 (only for Chrome) but looking at the ​Chromium ticket, it should be fixed in about a week.

[netweb]

I've previously suggested close in this ticket and I was wrong so I'm not going to suggest that again ;)

In Chrome Canary Version 47.0.2507.0 (64-bit) on Mac OS X this now looks resolved, i.e. I can no longer reproduce, it is still reproducible in the dev branch 47.0.2503.0 at this time.

[dd32]

#33855 was marked as a duplicate.

[ocean90]

#33880 was marked as a duplicate.

[helen]

Moving to 4.3.2 for tracking but assuming that Chrome's estimated timeline of this week is correct, we shouldn't need to change anything.

[pross]

Just updated to 45.0.2454.93 stable 64bit OSX problem seems to be solved.

[danielhuesken]

In Windows 10 it is solved to with 45.0.2454.93 m (64-bit).

[atomicjack]

Replying to danielhuesken:

In Windows 10 it is solved to with 45.0.2454.93 m (64-bit).

In the beta channel it is not resolved - sometimes the issue may not appear all the time.

[helen]

#33953 was marked as a duplicate.

[deadduck169]

I see that this bug is marked as "worksforme", however it is apparently only fixed in Chrome > 45.0.2454.93, and according to ​gs.statcounter.com Chrome usage for versions older than this is currently almost 100%, so basically it doesn't work for the majority of Chrome users (yet). It will be a few months before most people start using versions of Chrome with this fix included (not to mention Opera, which is a few months behind in their version of Chromium), so why not include a workaround to Wordpress for a few months to minimize the effect?

As you'll notice in #33953, I have tracked the bug down to the setPinMenu() function. Just add $adminmenu.hide().show(0); at the end of this function and the problem goes away. You could even add a small ​check to see which version of Chrome is installed so that the impact on users using non-affected browsers would be minimalized.

[azaozz]

Replying to deadduck169:

I see that this bug is marked as "worksforme", however it is apparently only fixed in Chrome > 45.0.2454.93, and according to ​gs.statcounter.com Chrome usage for versions older than this is currently almost 100%

Here Chrome is at version 45.0.2454.99 m (Win7) and the problem is fixed. Don't think future versions of Chrome will be without this fix.

As you'll notice in #33953, I have tracked the bug down to the setPinMenu() function.

The bug is caused by setting the menu container to position: fixed. This is done in couple different ways, including with setPinMenu() when scrolling.

[Ipstenu]

It will be a few months before most people start using versions of Chrome with this fix included ...

Given how Chrome updates, I suspect this will be much faster than months. Weeks maybe, but Chrome will yell at you if you don't update it regularly with that handy hamburger bar on the right :)

[SergeyBiryukov]

#34001 was marked as a duplicate.

[swissspidy]

#34155 was marked as a duplicate.