WordPress.org

Make WordPress Core

Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#33199 closed defect (bug) (worksforme)

Chrome 45 incorrectly renders admin menu

Reported by: atomicjack Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Administration Keywords:
Focuses: ui, administration Cc:

Description

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:

http://i.imgur.com/E0dK3HM.png

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

Attachments (9)

admin.gif (145.5 KB) - added by jcastaneda 2 years ago.
issue-33199-add-css-transform.patch (305 bytes) - added by ideasatrandom 2 years ago.
issue-33199-add-css-transform
Media Modal.png (121.6 KB) - added by atomicjack 2 years ago.
Media Modal displays correctly with this CSS change
Dropdowns.png (28.5 KB) - added by atomicjack 2 years ago.
Dropdowns display correctly
Menu Collapsed.png (25.3 KB) - added by atomicjack 2 years ago.
Menu Collapsed displays correctly
Menu Uncollapsed.png (41.9 KB) - added by atomicjack 2 years ago.
Menu Uncollapsed displays correctly
Responsive Menu 1.png (24.0 KB) - added by atomicjack 2 years ago.
Responsiveness of the menu works as expected
adminmenu.png (25.7 KB) - added by Design Wave 2 years ago.
adminmenu CSS transform fix
Settings-Menu-Still-Broken-Without-Patch 2015-09-05 21-14-33.png (59.2 KB) - added by ideasatrandom 2 years ago.
Settings menu still broken without CSS transform patch

Download all attachments as: .zip

Change History (119)

#1 follow-up: @SergeyBiryukov
2 years ago

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

#2 in reply to: ↑ 1 @atomicjack
2 years ago

  • Status changed from new to closed

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.

#3 @atomicjack
2 years ago

  • Status changed from closed to reopened

Apparently my keyboard closed this ticket by mistake - opened.

#4 @dmchale
2 years ago

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.

This ticket was mentioned in Slack in #core by obenland. View the logs.


2 years ago

#6 @ocean90
2 years ago

  • Version trunk deleted

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.

#7 @atomicjack
2 years ago

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.

#8 @ocean90
2 years ago

#33274 was marked as a duplicate.

#9 @nicola.peluchetti
2 years ago

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

#10 @atomicjack
2 years ago

  • Severity changed from normal to major
  • Version set to trunk

#11 @ocean90
2 years ago

  • Severity changed from major to normal
  • Version trunk deleted

#12 follow-up: @netweb
2 years ago

  • Keywords close added

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)

#13 in reply to: ↑ 12 @netweb
2 years ago

  • Keywords close removed

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 :(

#14 @pier25
2 years ago

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

#15 follow-up: @pier25
2 years ago

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

Last edited 2 years ago by pier25 (previous) (diff)

#16 in reply to: ↑ 15 @atomicjack
2 years ago

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.

#17 @atomicjack
2 years ago

Still an issue in 45.0.2454.26 beta.

#18 @atomicjack
2 years ago

Present in 45.0.2454.37 beta.

#19 @upct
2 years ago

Same problem here with Chrome Version 45.0.2454.37 beta-m

#20 @obenland
2 years ago

#33445 was marked as a duplicate.

#21 @KoenRijpstra
2 years ago

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

This ticket was mentioned in Slack in #core by helen. View the logs.


2 years ago

#23 @pross
2 years ago

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

#24 @ryan
2 years ago

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

#26 @SergeyBiryukov
2 years ago

#33666 was marked as a duplicate.

This ticket was mentioned in Slack in #core by sergey. View the logs.


2 years ago

@jcastaneda
2 years ago

#29 @jcastaneda
2 years ago

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

#30 @joefletcher
2 years ago

@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

#31 @Otto42
2 years ago

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>

#32 @knutsp
2 years ago

#33445 was marked as a duplicate.

#33 @bobcatou
2 years ago

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.

#34 follow-up: @elementpz
2 years ago

#adminmenu {
  transform: translateZ(0);
}

Here you go :)

#35 @SergeyBiryukov
2 years ago

  • Milestone changed from Awaiting Review to 4.3.1

#36 follow-up: @atomicjack
2 years ago

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.

#37 @kalich5
2 years ago

I have same problem.

#38 @igmoweb
2 years ago

Same issue for me in all my sites.

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

#39 @raffjones
2 years ago

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

#40 follow-up: @atomicjack
2 years ago

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.

#41 in reply to: ↑ 40 @raffjones
2 years ago

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.

#42 in reply to: ↑ 36 @netweb
2 years ago

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

#43 follow-up: @Otto42
2 years ago

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); }' );
}

#44 in reply to: ↑ 43 @raffjones
2 years ago

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

#45 follow-up: @Otto42
2 years ago

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.

Last edited 2 years ago by Otto42 (previous) (diff)

#46 @upct
2 years ago

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

Thanks again !

#47 @swissspidy
2 years ago

#33708 was marked as a duplicate.

#48 in reply to: ↑ 45 ; follow-up: @Howdy_McGee
2 years ago

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?

#49 in reply to: ↑ 48 @Otto42
2 years ago

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.

#50 @zenjiweb
2 years ago

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
2 years ago

issue-33199-add-css-transform

#51 follow-up: @ideasatrandom
2 years ago

  • Keywords has-patch added

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.

#52 @SergeyBiryukov
2 years ago

#33718 was marked as a duplicate.

#53 @atomicjack
2 years ago

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

#54 in reply to: ↑ 51 ; follow-up: @atomicjack
2 years ago

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... :)

#55 in reply to: ↑ 54 ; follow-up: @Design Wave
2 years ago

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

#56 in reply to: ↑ 55 ; follow-up: @atomicjack
2 years ago

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?

#57 in reply to: ↑ 56 ; follow-up: @johnjamesjacoby
2 years ago

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.

#58 in reply to: ↑ 57 ; follow-up: @atomicjack
2 years ago

  • Keywords needs-testing added

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.

#59 in reply to: ↑ 58 @johnjamesjacoby
2 years ago

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.

#60 @atomicjack
2 years ago

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
2 years ago

Media Modal displays correctly with this CSS change

@atomicjack
2 years ago

Dropdowns display correctly

@atomicjack
2 years ago

Menu Collapsed displays correctly

@atomicjack
2 years ago

Menu Uncollapsed displays correctly

@atomicjack
2 years ago

Responsiveness of the menu works as expected

#61 @atomicjack
2 years ago

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.

#62 follow-up: @zenjiweb
2 years ago

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

#63 in reply to: ↑ 62 ; follow-up: @atomicjack
2 years ago

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.

#64 @danieltj
2 years ago

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.

This ticket was mentioned in Slack in #core by eric. View the logs.


2 years ago

@Design Wave
2 years ago

adminmenu CSS transform fix

#66 follow-up: @Design Wave
2 years ago

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.

#67 in reply to: ↑ 63 ; follow-up: @zenjiweb
2 years ago

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.

#68 in reply to: ↑ 67 @Design Wave
2 years ago

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

#69 @SergeyBiryukov
2 years ago

#33733 was marked as a duplicate.

#70 @Viper007Bond
2 years ago

  • Summary changed from Admin Menu Items Break to Chrome 45 incorrectly renders admin menu

#71 @Marcoevich
2 years ago

#33739 was marked as a duplicate.

#72 @Clorith
2 years ago

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

@ideasatrandom
2 years ago

Settings menu still broken without CSS transform patch

#73 in reply to: ↑ 66 @ideasatrandom
2 years ago

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?

Last edited 2 years ago by ideasatrandom (previous) (diff)

#74 @crzyhrse
2 years ago

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.

Last edited 2 years ago by crzyhrse (previous) (diff)

#75 @atomicjack
2 years ago

#33761 was marked as a duplicate.

#76 @atomicjack
2 years ago

#33762 was marked as a duplicate.

This ticket was mentioned in Slack in #core by jasond33. View the logs.


2 years ago

#78 @swissspidy
2 years ago

#33765 was marked as a duplicate.

#79 @miqrogroove
2 years ago

  • Priority changed from normal to highest omg bbq

#80 in reply to: ↑ 34 @vaschops
2 years ago

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

Last edited 2 years ago by vaschops (previous) (diff)

#81 @ocean90
2 years ago

#33781 was marked as a duplicate.

#82 in reply to: ↑ description @myrecipepicks
2 years ago

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:

http://i.imgur.com/E0dK3HM.png

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.

#83 @pento
2 years ago

#33784 was marked as a duplicate.

#84 @atomicjack
2 years ago

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

#85 follow-up: @swissspidy
2 years ago

#33788 was marked as a duplicate.

#86 in reply to: ↑ 85 @sksdev
2 years ago

Replying to swissspidy:

#33788 was marked as a duplicate.

Thanks for confirmation

#87 follow-up: @inderpreet99
2 years ago

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

#88 in reply to: ↑ 87 ; follow-up: @miqrogroove
2 years ago

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?

#89 in reply to: ↑ 88 @atomicjack
2 years ago

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.

#90 @SergeyBiryukov
2 years ago

#33792 was marked as a duplicate.

#91 @Otto42
2 years ago

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

This ticket was mentioned in Slack in #core by swissspidy. View the logs.


2 years ago

#93 @inderpreet99
2 years ago

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! :)

#94 @azaozz
2 years ago

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.

#95 @netweb
2 years ago

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.

#96 @dd32
2 years ago

#33855 was marked as a duplicate.

#97 @ocean90
2 years ago

#33880 was marked as a duplicate.

#98 @helen
2 years ago

  • Milestone changed from 4.3.1 to 4.3.2

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.

#99 @pross
2 years ago

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

#100 follow-up: @danielhuesken
2 years ago

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

#101 in reply to: ↑ 100 @atomicjack
2 years ago

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.

#102 @ocean90
2 years ago

  • Keywords has-patch needs-testing removed
  • Milestone 4.3.2 deleted
  • Priority changed from highest omg bbq to normal
  • Resolution set to worksforme
  • Status changed from reopened to closed

#103 @atomicjack
2 years ago

  • Resolution worksforme deleted
  • Status changed from closed to reopened

#104 @atomicjack
2 years ago

  • Resolution set to worksforme
  • Status changed from reopened to closed

#105 @helen
2 years ago

#33953 was marked as a duplicate.

#106 follow-up: @deadduck169
2 years ago

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.

#107 in reply to: ↑ 106 @azaozz
2 years ago

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.

#108 @Ipstenu
2 years ago

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 :)

#109 @SergeyBiryukov
2 years ago

#34001 was marked as a duplicate.

#110 @swissspidy
2 years ago

#34155 was marked as a duplicate.

Note: See TracTickets for help on using tickets.