New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 147 users

Comments by non-members will not trigger notification emails to users who starred this issue.

Issue metadata

Status: Fixed
Owner:
Closed: Sep 2015
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Regression



Sign in to add a comment

The WordPress administration panel is not displayed properly

Reported by frederic...@gmail.com, Jul 11 2015 Back to list

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2453.0 Safari/537.36

Example URL:

Steps to reproduce the problem:
1. Go to a WordPress site
2. Enter the administration panel

What is the expected behavior?

What went wrong?
The nav bar in the left is not displayed properly

Does it occur on multiple sites: Yes

Is it a problem with a plugin? N/A 

Did this work before? Yes Not sure.

Does this work in other browsers? Yes 

Chrome version: 45.0.2453.0  Channel: n/a
OS Version: 6.3
Flash Version: Shockwave Flash 18.0 r0

I have accesses to multiple WordPress sites which are all the latest 4.2.2 version and they all have the problem.

 
Showing comments 3 - 102 of 102 Older
Can you provide a screenshot?
Oh sorry, I forgot to attach it. Here it is.
1.png
20.3 KB View Download
Cc: brajkumar@chromium.org
Labels: Needs-Feedback
Tested on Windows 7 using chrome stable M43 - 43.0.2357.130 by following steps mentioned below.

1. Navigated to Wordpress.com
2. Created a free account
3. Navigated to the administration panel
4. Changed language to Japanese and Chinese
5. Observed the left panel is rendering properly 

Frederick888@ - Could you please upgrade chrome to current stable - 43.0.2357.130 and recheck this issue, if issue still persists let us know exactly on which language the rendering problem is displayed.
Render.JPG
24.0 KB View Download
It's a problem of the canary channel, the stable one is ok.

And you'd better download a package of wordpress from https://wordpress.org/, it's different from wordpress.com.

Both Japanese and Chinese here are displayed improperly. Here's the screenshot of the Chinese one.
1.png
14.6 KB View Download

Comment 7 Deleted

Comment 8 by Deleted ...@, Jul 17 2015

I'm having the same issue on 45.0.2454.7 dev (not the canary branch).
Screen Shot 2015-07-17 at 11.42.17 AM.png
19.7 KB View Download
Confirmed in 46.0.2467.0 canary (64-bit) with WP 4.2.3
Confirmed in 46.0.2473.0 canary (64-bit) with WP 4.2.4
It seems that if you un-check and re-check any CSS rule for an element in the nav bar, the problem will be fixed temporarily.
https://youtu.be/gTR5mBWunbU
 Issue 520402  has been merged into this issue.

Comment 13 by znu...@gmail.com, Aug 22 2015

Another relatively easy fix is to collapse the navigation menu.
Confirmed in 47.0.2497.0 canary (64-bit) but it seemed to be better (not always happen).
The problem now influences the stable channel. Confirmed in 45.0.2454.85 (64-bit) under Linux.
Experiencing this issue in the (now) stable channel. Version 45.0.2454.85 (64-bit). Mac OSX Yosemite.

If I use the dev tools and uncheck then re-check one of the CSS properties for an element inside the nav <ul> then, it appears, that the browser repaints and the error goes away.
 
Screen Shot 2015-09-02 at 10.55.10 AM.png
6.2 KB View Download

Comment 17 by wjy...@gmail.com, Sep 2 2015

I did a bisect of this issue:

Bisecting range [334680 (good), 334702 (bad)].
Trying revision 334686...
Revision 334686 is [(g)ood/(b)ad/(r)etry/(u)nknown/(q)uit]: b
You are probably looking for a change made after 334680 (known good), but no later than 334686 (first known bad).
CHANGELOG URL:

https://chromium.googlesource.com/chromium/src/+log/a73bf29bc9385ba1b1a4f9a2122b0eceee44100b..260fd855786fb493ad780eb0a5a3681e50d0f941

I verified that this was caused by 260fd855786fb493ad780eb0a5a3681e50d0f941 "Enable Slimming Paint by default in Chromium and Blink". After adding --disable-slimming-paint command line, this issue disappeared.

Comment 18 by Deleted ...@, Sep 3 2015

Version 45.0.2454.85 (64-bit).
10.10.5 (14F27) Yosemite
WP version 4.3

I can report this happening too.
When I open inspector the problem corrects itself so I cant see exactly what the issue is.
Screen Shot 2015-09-02 at 10.02.17 PM.png
12.7 KB View Download

Comment 19 by net...@gmail.com, Sep 3 2015

This issue is currently being tracked by WordPress in the following ticket:

https://core.trac.wordpress.org/ticket/33199

The issue has affected the dev and canary channels for ~5 weeks now though as this is now affecting the stable branch as of Chrome we're seeing many more users reporting the issue today.
Can confirm that disable-slimming-paint prevents the issue.

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

Enable the Disable slimming paint flag.
Ensure that the Enable slimming paint flag below it is not turned on.
Relaunch Chrome.

Menus render normally again.

Comment 21 Deleted

Comment 22 by Deleted ...@, Sep 3 2015

I'll also confirm that enabling the Disable slimming paint flag addresses this issue. 

Comment 23 by Deleted ...@, Sep 3 2015

using this solved my issue:

chrome://flags/#disable-slimming-paint
Labels: -Cr-Blink Cr-Blink-Paint
Tagging as Cr-Blink-Paint so that it gets triaged.
I can't reproduce on TOT linux with japanese interface font.
OK I think I can repro actually, it doesn't stay in a weird state, but it flashes in the left menu briefly weird, and doesn't do so when slimming paint is off.

The magic to get to the console is to go to yourusername.wordpress.com/wp-admin

I get the same results regardless of language.
Owner: chrishtr@chromium.org
Status: Untriaged (was: NULL)
Labels: -OS-Windows -Arch-x86_64 -Needs-Feedback OS-All

Comment 29 by wjy...@gmail.com, Sep 3 2015

I continued the bisect with --enable-slimming-paint to get the bad blink roll.

Bisecting range [327894 (good), 327896 (bad)].
Trying revision 327895...
Revision 327895 is [(g)ood/(b)ad/(r)etry/(u)nknown/(q)uit]: b
You are probably looking for a change made after 327894 (known good), but no later than 327895 (first known bad).
NOTE: There is a Blink roll in the range, you might also want to do a Blink bisect.
CHANGELOG URL:

https://chromium.googlesource.com/chromium/src/+log/b611ff37a166f2479a3ff7686de09baf92ec893a..16ac363a343dc68817aa70f24d885f7343f8ca6a

I suspect this was caused by blink commit "[Reland] Correct fixed-position recording for Slimming Paint":
https://chromium.googlesource.com/chromium/blink/+/0d6c3f0c797a6b26d99487b01aba465caf095a25
Cc: ligim...@chromium.org chrishtr@chromium.org
Labels: -Type-Bug Type-Bug-Regression M-47
Owner: trchen@chromium.org
Status: Assigned (was: NULL)
Assigning to the suspected CL owner , Tien for further updates.

Tagging this with M47, since M45 is already in stable.
I can Reproduce the issue with Chrome Version 45.0.2454.85 (64-bit) Mac and Carnary Build Version 47.0.2501.0 canary (64-bit).

I found out, the issue is just occurs if the window height is bigger than the Menu height. This may help to pinpoint down the Error.
 
The Slimming Paint fix works


Cc: kavvaru@chromium.org
 Issue 527897  has been merged into this issue.
 Issue 527657  has been merged into this issue.

Comment 34 Deleted

Running into same issue and I work in 10-15 Wordpress Sites/Backends per day, all of them affected on Chrome. Attached is the screenshot, someone mentioned turning slimming paint off would help. Windows 7 Pro - Chrome Version 45.0.2454.85 m - 10:19am EST
111.jpg
20.2 KB View Download
Labels: -Pri-2 Pri-1 ReleaseBlock-Beta
Hello everyone!

It is possible also to fix the problem by adding the following action to a wordpress'functions.php file.

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

Regards!
G.

Comment 38 by Deleted ...@, Sep 6 2015

Same issue also, the above fixed worked perfectly!
Same problem. Tried suggestion from '#37 giovani' and it appears to have worked.

Comment 40 Deleted

Comment 41 Deleted

I've got this too. Using this helped me too: chrome://flags/#disable-slimming-paint

I don't know if it has any side effects though.
Thanks #42 easyg. This seems to work.
Barring unknown side effects, this is better for me than adding the admin_menu_fix() code to the functions.php files for all my sites.
mi wordpress tambien se ve feo, arreglen este pinche bug
Thank-you @giovani for the more appropriate fix. Works great.

Comment 46 by Deleted ...@, Sep 8 2015

I'm experiencing this issue in Version 45.0.2454.85 (64-bit) (osx). Latest build apparently. I've only seen this issue on the WordPress nav. Looks like it's taking an awfully long time to fix? I'm not looking for a workaround.
I'm experiencing this bug on Redhat Fedora GNU/Linux running Chrome 45.0.2454.85 (64-bit). It affects all the wordpress websites I manage.

Comment 48 by wfh@chromium.org, Sep 8 2015

Cc: pdr@chromium.org
 Issue 529038  has been merged into this issue.

Comment 49 by wfh@chromium.org, Sep 8 2015

This slimming paint issue is affecting quite a few sites, can we get an update on this - is the markup incorrect on the affected sites (and if so, what is the correct fix), or is this a rendering issue in Chrome?
I think it's a real bug. We will follow up soon with triage and analysis. Thanks for your patience.

Comment 51 by Deleted ...@, Sep 8 2015

The solution from #37 giovani....@gmail.com Works Perfect!

Add this:

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

To your wp function.php OR functions.wp-styles.php

Comment 52 by Deleted ...@, Sep 8 2015

#51's recommendation indeed works for me too. That glitch was getting really annoying.
Owner: pdr@chromium.org

Comment 54 by Deleted ...@, Sep 8 2015

Hello. I have this issue in http://www.saudeocupacional.org. The admin menu issue was fixed with the #37 giovani....@gmail.com function, but the front-end keep flashing and glitching.

Has any fix to front-end bug?

Thank you in advance.

Bruno.

Comment 55 by and...@poisar.com, Sep 8 2015

Running Windows 10 and run dozens of WordPress sites. Experiencing the issue on all of them. Running Microsoft "Edge" fixed the issue for me.

Comment 56 by pdr@chromium.org, Sep 8 2015

Status: Started (was: NULL)
Thanks for all the reports. To keep from spamming other posters, please just star the issue instead of adding comments such as "me too".

Does anyone happen to have a public url that this reproduces on? I'm going to try to find a wordpress install in the meantime.

Comment 57 by pdr@chromium.org, Sep 8 2015

That was easy. I have a repro (via a free wordpress.com account), now working on a fix.

Comment 58 by and...@poisar.com, Sep 9 2015

Go to dev.poisar.com/wp-admin
Username: dev
Password P@ss1234!

Please login and change the password to your liking. I'll keep the image up for however long you need. If you need further credentials (such as FTP) then please let me know.

- Andrew Koski

Comment 59 by wfh@chromium.org, Sep 9 2015

Re #56 there is an reliable repro in  issue 529038  that I used to bisect.

https://www.kolumbus-sprachreisen.de/sprachreisen

Comment 60 by pdr@chromium.org, Sep 9 2015

Labels: -M-47 M-46 Needs-Bisect
With andrew@poisar...'s help I created a local repro of the wordpress issue (see attached wordpress_unminimized.zip) which has been fixed on the main wordpress site. I've added Needs-Bisect for a bisect of wordpress_unminimized.zip, specifically the underpainting seen in the left panel in the repro.html file.

 issue 529038  feels like a different bug because it shows garbage memory along compositor tile boundaries, whereas the wordpress issue looks like a paint invalidation bug. I'm going to hold off on de-duping for now though.

For folks affected by this bug: please star this bug if you'd like updates. I don't have an ETA, but I'll keep this bug updated as I know more. The issue appears to be related to position:fixed elements and adding "transform: translateZ(0)" has been a successful workaround for a few sites.
wordpress_unminimized.zip
368 KB Download
So after struggling with this for months now, thinking it was an extension, I can confirm that the disable-slimming-paint trick works for my 2 wordpress sites in Chrome Version 46.0.2490.13 beta-m (64-bit).

But seriously though - 2 months and it STILL needs a workaround?

I wonder if this might be related to the gmail folder list weirdness I've been seeing? Sometimes there'll be two Spams and no Bin, or two Inboxes and no Starred. Fixed by refreshing the page. A bit random, but I've not seen it since doing the repaint fix (only 2 hours ago though, so can't say for certain).
Same problem here with all my sites (arround 12)
I using the Dutch version of WP 4.3 

Comment 63 by wfh@chromium.org, Sep 9 2015

Cc: trchen@chromium.org
bisected repro.html from #60 with --enable-slimming-paint flag set and came to blink revs

https://chromium.googlesource.com/chromium/blink/+log/eb2a234..6f61d88?pretty=fuller

possibly 0d6c3f0c797a6b26d99487b01aba465caf095a25

+trchen

Comment 64 Deleted

Comment 65 by tin...@google.com, Sep 9 2015

Labels: -ReleaseBlock-Beta ReleaseBlock-Stable
We're in M46 Beta range already, updating the label to target M46 Stable launch.

Comment 66 by pdr@chromium.org, Sep 9 2015

Labels: -Needs-Bisect
Thanks wfh.
Starred. Needs a fix ASAP for those such as myself who do not use other browsers and have everything Google/Chrome centric.
Hej, Guys!

I know this might not be the focus of the discussion,
but I just came across the very same problem with Owl Carousel
and I think it could help somebody out...
(http://www.owlcarousel.owlgraphic.com/demos/demos.html)

When using fancy transitions between the slides (with animate.css plugin)
some effects are bringing erratic blinking/loading problems during animation.

It is easy to spot the problems on this demo:
http://www.owlcarousel.owlgraphic.com/demos/lazyLoad.html

Run it on Chrome and Firefox. For testing - while on Chrome -
navigate between slides on a fast fashion. You will notice
the "lazy loading" effect is not working correctly
when compared to the same demo running on Firefox.

To fix the problem on Owl Carousel I did apply the very
same CSS fix we have been "enqueueing" on our Wordpress'
admin style.

Fix for Owl Carousel:
.owl-carousel .owl-item { transform: translateZ(0); }

Regards,
G.
In time: I needed to add the fix also to:
.owl-carousel .owl-item img { transform: translateZ(0); }

Comment 70 by pdr@chromium.org, Sep 9 2015

Minimized this down to a small testcase (see: minimized.html)

I also confirmed this is a regression from https://chromium.googlesource.com/chromium/blink/+/0d6c3f0c797a6b26d99487b01aba465caf095a25

I'm working on a fix now.
minimized.html
522 bytes View Download
Project Member

Comment 71 by bugdroid1@chromium.org, Sep 10 2015

The following revision refers to this bug:
  http://src.chromium.org/viewvc/blink?view=rev&rev=202060

------------------------------------------------------------------
r202060 | pdr@chromium.org | 2015-09-10T16:38:37.040832Z

Changed paths:
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/TestExpectations?r1=202060&r2=202059&pathrev=202060
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/paint/invalidation/fixed-position-with-text-expected.html?r1=202060&r2=202059&pathrev=202060
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/layout/LayoutObject.cpp?r1=202060&r2=202059&pathrev=202060
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/paint/invalidation/fixed-position-with-text.html?r1=202060&r2=202059&pathrev=202060
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/platform/mac/fast/forms/button/button-reset-focus-by-mouse-then-keydown-expected.txt?r1=202060&r2=202059&pathrev=202060
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/platform/mac/fast/forms/submit/submit-focus-by-mouse-then-keydown-expected.txt?r1=202060&r2=202059&pathrev=202060

Invalidate all non-composited descendants on fixed-position changes

This patch updates invalidateDisplayItemClientForNonCompositingDescendants
to use LayoutObject::invalidateDisplayItemClients(...) instead of manually
calling invalidateDisplayItemClientOnBacking. These two functions are
deceptively similar but invalidateDisplayItemClients is virtual and
can perform additional invalidations in some subclasses. One example is
LayoutInline which invalidates flow-box children in addition to itself.

This fixes a regression caused by [1] where fixed-pos changes would
only invalidate LayoutObject non-composited descendants and would forget
about its inline text friends.

[1] https://chromium.googlesource.com/chromium/blink/+/0d6c3f0c797a6b26d99487b01aba465caf095a25

BUG= 509179 

Review URL: https://codereview.chromium.org/1330993002
-----------------------------------------------------------------

Comment 72 by pdr@chromium.org, Sep 10 2015

Labels: Merge-Request-46
Requesting a merge into M46 as this is a fairly straightforward change.

For folks affected: Chrome Canary will spin tonight and this fix will be live in Canary in about 24 hours if you'd like to test your site. I verified this does fix Wordpress. I think we'll be able to merge this to M46 (currently Beta) but we've missed the M45 (Stable) train so this will likely remain broken until M46 hits stable.
No chance of getting this into some kind of interim 45 patch? This breaks every WordPress site. Millions of users. 20-30% of the web. The damage to Chrome is real. Many are recommending switching to Firefox or even edge to prevent this sort of thing in the future. A really fast fix would help everybody a whole lot here.
According to a Wordpress Trac user simply type the following in the address bar of a new tab.

chrome://flags

Then scroll down until you see "Disable slimming paint. Mac, Windows, Linux, Chrome OS, Android".  Click "Enable".  Note: this does NOT enable slimming paint, it DISABLES it.

Click the RELAUNCH NOW button.

Problem solved.

I have personally tested this and it solves the problem 100%

Slimming Paint is now turned on by default in Chrome.
Additonal info to my previous comment for a fix.

Slimming Paint being turned by default is what is causing the problem in the WordPress admin menu. So follow my instructions in comment 74 to disable it and your WordPress admin menu will work fine.


Comment 76 by Deleted ...@, Sep 11 2015

I will throw in here that disabling slimming paint works fine for the very few of us privy to this thread and/or to the Wordpress ticket about this issue, but it does absolutely nothing for the many millions of folks potentially affected by this around the world, RE; #73...
I agree with SpadeG. Unfortunately many WordPress users are not tech savy enough to understand how to fully troubleshoot website issues, reporting them to WordPress (which is how I found this thread/fix), and certainly does nothing for website admins who outsource their website design to third-parties but use the admin panel.

This slimming paint feature is clearly an experimental feature that has back fired big time and should have never been turned on by default.

Comment 79 by amin...@google.com, Sep 11 2015

Labels: -Merge-Request-46 Merge-Approved-46 Merge-Approved-45
Let's get this into 45 (branch 2454) and 46 (branch 2490), approved for both.
Project Member

Comment 80 by bugdroid1@chromium.org, Sep 11 2015

Labels: -Merge-Approved-46 merge-merged-2490
The following revision refers to this bug:
  http://src.chromium.org/viewvc/blink?view=rev&rev=202148

------------------------------------------------------------------
r202148 | pdr@chromium.org | 2015-09-11T17:31:50.395499Z

Changed paths:
   A http://src.chromium.org/viewvc/blink/branches/chromium/2490/LayoutTests/paint/invalidation/fixed-position-with-text-expected.html?r1=202148&r2=202147&pathrev=202148
   M http://src.chromium.org/viewvc/blink/branches/chromium/2490/Source/core/layout/LayoutObject.cpp?r1=202148&r2=202147&pathrev=202148
   A http://src.chromium.org/viewvc/blink/branches/chromium/2490/LayoutTests/paint/invalidation/fixed-position-with-text.html?r1=202148&r2=202147&pathrev=202148
   M http://src.chromium.org/viewvc/blink/branches/chromium/2490/LayoutTests/platform/mac/fast/forms/button/button-reset-focus-by-mouse-then-keydown-expected.txt?r1=202148&r2=202147&pathrev=202148
   M http://src.chromium.org/viewvc/blink/branches/chromium/2490/LayoutTests/platform/mac/fast/forms/submit/submit-focus-by-mouse-then-keydown-expected.txt?r1=202148&r2=202147&pathrev=202148
   M http://src.chromium.org/viewvc/blink/branches/chromium/2490/LayoutTests/TestExpectations?r1=202148&r2=202147&pathrev=202148

Merge 202060 "Invalidate all non-composited descendants on fixed..."

> Invalidate all non-composited descendants on fixed-position changes
> 
> This patch updates invalidateDisplayItemClientForNonCompositingDescendants
> to use LayoutObject::invalidateDisplayItemClients(...) instead of manually
> calling invalidateDisplayItemClientOnBacking. These two functions are
> deceptively similar but invalidateDisplayItemClients is virtual and
> can perform additional invalidations in some subclasses. One example is
> LayoutInline which invalidates flow-box children in addition to itself.
> 
> This fixes a regression caused by [1] where fixed-pos changes would
> only invalidate LayoutObject non-composited descendants and would forget
> about its inline text friends.
> 
> [1] https://chromium.googlesource.com/chromium/blink/+/0d6c3f0c797a6b26d99487b01aba465caf095a25
> 
> BUG= 509179 
> 
> Review URL: https://codereview.chromium.org/1330993002

TBR=pdr@chromium.org

Review URL: https://codereview.chromium.org/1335223002
-----------------------------------------------------------------
Project Member

Comment 81 by bugdroid1@chromium.org, Sep 11 2015

Labels: -Merge-Approved-45 merge-merged-2454
The following revision refers to this bug:
  http://src.chromium.org/viewvc/blink?view=rev&rev=202149

------------------------------------------------------------------
r202149 | pdr@chromium.org | 2015-09-11T17:35:53.022484Z

Changed paths:
   A http://src.chromium.org/viewvc/blink/branches/chromium/2454/LayoutTests/paint/invalidation/fixed-position-with-text-expected.html?r1=202149&r2=202148&pathrev=202149
   M http://src.chromium.org/viewvc/blink/branches/chromium/2454/Source/core/layout/LayoutObject.cpp?r1=202149&r2=202148&pathrev=202149
   A http://src.chromium.org/viewvc/blink/branches/chromium/2454/LayoutTests/paint/invalidation/fixed-position-with-text.html?r1=202149&r2=202148&pathrev=202149
   M http://src.chromium.org/viewvc/blink/branches/chromium/2454/LayoutTests/platform/mac/fast/forms/button/button-reset-focus-by-mouse-then-keydown-expected.txt?r1=202149&r2=202148&pathrev=202149
   M http://src.chromium.org/viewvc/blink/branches/chromium/2454/LayoutTests/platform/mac/fast/forms/submit/submit-focus-by-mouse-then-keydown-expected.txt?r1=202149&r2=202148&pathrev=202149
   M http://src.chromium.org/viewvc/blink/branches/chromium/2454/LayoutTests/TestExpectations?r1=202149&r2=202148&pathrev=202149

Merge 202060 "Invalidate all non-composited descendants on fixed..."

> Invalidate all non-composited descendants on fixed-position changes
> 
> This patch updates invalidateDisplayItemClientForNonCompositingDescendants
> to use LayoutObject::invalidateDisplayItemClients(...) instead of manually
> calling invalidateDisplayItemClientOnBacking. These two functions are
> deceptively similar but invalidateDisplayItemClients is virtual and
> can perform additional invalidations in some subclasses. One example is
> LayoutInline which invalidates flow-box children in addition to itself.
> 
> This fixes a regression caused by [1] where fixed-pos changes would
> only invalidate LayoutObject non-composited descendants and would forget
> about its inline text friends.
> 
> [1] https://chromium.googlesource.com/chromium/blink/+/0d6c3f0c797a6b26d99487b01aba465caf095a25
> 
> BUG= 509179 
> 
> Review URL: https://codereview.chromium.org/1330993002

TBR=pdr@chromium.org

Review URL: https://codereview.chromium.org/1333373002
-----------------------------------------------------------------

Comment 82 by pdr@chromium.org, Sep 11 2015

Status: Fixed (was: NULL)
Houston, we've landed in all branches!

For folks affected by this bug: you can test this fix today in Chrome Canary (m47). This will not roll out immediately in beta (m46) and stable (m45), but it is queued up to be pushed soon (on the order of ~1 week).

Comment 83 by Deleted ...@, Sep 12 2015

Confirmed - Fixed finally! Thank you!

Comment 84 by Deleted ...@, Sep 12 2015

Yes - confirmed fix in 47.0.2507.0 on Mac. Thanks a lot for the response and fix.
I confirm this problem with Chrome Version 45.0.2454.85 (64-bit) on Ubuntu 14.04
> I confirm this problem with Chrome Version 45.0.2454.85 (64-bit) on Ubuntu 14.04

Can you reproduce the issue on the canary channel[1]?

[1] https://www.google.com/chrome/browser/canary.html
#86 I can't install and try canary on Ubuntu... or you have to tell me how ? sorry,
> #86 I can't install and try canary on Ubuntu... or you have to tell me how ? sorry,

Apologies, Chrome Canary is not available on Linux. Can you reproduce the issue on the dev channel[1]?

[1] https://www.google.com/chrome/browser/desktop/index.html?extra=devchannel

Comment 89 by pdr@chromium.org, Sep 14 2015

The fix hasn't yet rolled out to dev channel on linux (https://omahaproxy.appspot.com, look for current_reldate after 9/12) but will be in the next dev channel update. For most developers, I recommend waiting for this to roll out to canary (mac, win), or dev (linux, mac, win, android).

If you're very keen on trying out the fix you can grab a continuous build (completely untested) for linux here:
http://commondatastorage.googleapis.com/chromium-browser-continuous/index.html?prefix=Linux_x64/345859
Labels: Needs-Feedback
Tested the issue on windows 7, Linux Ubuntu 14.04 and Mac 10.10.5 using chrome version 45.0.2454.93 with the below steps

1. Enable #enable-slimming-paint from chrome flags
2. Opened the minimized html file from comment #70
3. Not observed any render issues

pdr@ : Could you please find the attached screen cast, steps and confirm anything missed here to verify.Please provide us the repro steps to verify the issue from our end.

Thanks in advance!
509179.mp4
744 KB Download

Comment 91 by Deleted ...@, Sep 14 2015

Hi,

I managed to replicate this on other custom website menus and not just word press. I am still having the issue on Chrome in Windows 7. When do you think this be available for Windows Chrome?

Many Thanks
Turning off Slimming Paint has a drawback, since i turned it off my WP Menu is working fine, but since then i lose focus between tabs and when switching from one to the other
and try to write something in a text field, i have to click on the tab first to give it focus.
This is kinda getting on my nerves lately.
Labels: -Needs-Feedback TE-Verified-45.0.2454.93 TE-Verified-47.0.2508.0 TE-Verified-M45 TE-Verified-M47
Tested the fix on Latest Chrome Stable#45.0.2454.93 & Canary# 47.0.2508.0 for Win7 64-bit OS, Mac OS X 10.10.5 & Linux Ubuntu 14.04 - Working as intended.

Attached the screenshot for your reference. I have used both 'repro.html (per C#60)' & 'minimized.html (per C#70)' to verify the fix.

Thank you!
509179.png
136 KB View Download

Comment 94 by Deleted ...@, Sep 15 2015

Hi,

I am still at Version 45.0.2454.85 m. When will this be released to all channels?

Many Thanks!

Comment 95 by Deleted ...@, Sep 16 2015

Fixed for me in Version 45.0.2454.93 (64-bit). Thanks!

Comment 96 by reza...@gmail.com, Sep 16 2015

Yes Fix for me too :)
Google Chrome45.0.2454.93 (Official Build) m (32-bit)Revision
ba1cb72081c2c07e4b689082852b1463fbca95f5-refs/branch-heads/2454@{#466}OS
Windows Blink537.36 (@202161)JavaScriptV8 4.5.103.31Flash18.0.0.232User
AgentMozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like
Gecko) Chrome/45.0.2454.93 Safari/537.36Command Line"C:\Program Files
(x86)\Google\Chrome\Application\chrome.exe" --flag-switches-begin
--flag-switches-endExecutable PathC:\Program Files
(x86)\Google\Chrome\Application\chrome.exeProfile
PathC:\Users\Rezaur\AppData\Local\Google\Chrome\User
Data\DefaultVariations47f591a-3f4a17df
74785582-3f4a17df
6345b824-3d47f4f4
7c1bc906-f55a7974
e9f4800b-39c30599
8afebf76-22b4d9c0
19f73432-ca7d8d80
76b48ab8-a2567007
c70841c8-a2567007
195ce1b5-d93a0620
9d315c2-ca7d8d80
fb124cc-3d47f4f4
93731dca-3f4a17df
1d3ad72e-3f4a17df
9e5c75f1-e1c7cd46
f79cb77b-3d47f4f4
97dfc274-3f4a17df
ca65a9fe-91ac3782
4ea303a6-a533950d
fa99bb73-3f4a17df
7aa46da5-669a04e0
9736de91-ca7d8d80
5c3cc7b1-ca7d8d80
b2612322-8a9180b2
2ce2968c-57e3669a
c99b9cf4-3f4a17df
244ca1ac-4ad60575
f47ae82a-746c2ad4
3ac60855-486e2a9c
f296190c-495cc57e
4442aae2-6e597ede
ed1d377-e1cc0f14
75f0f0a0-e1cc0f14
e2b18481-7158671e
e7e71889-4ad60575
b39ea213-d1372334
Thanks you very much.

Comment 97 by Deleted ...@, Sep 16 2015

Google Chrome 45.0.2454.93 it has been fixed there and for 45.0.2454.95 as well.
We have an issue with the Gantry 5 template administration panel for Joomla (www.rockettheme.com) for menus not being properly displayed in Chrome 45.0.2454.99 m (64-bit) or 47.0.2516.0 canary (64-bit). When we apply the above flag to disable the Slimming Paint it works. There is no problem in Firefox. So, there still is a issue with this bug, it is not fixed.
Re comment #98: please file a new bug with instructions on how to reproduce.
Project Member

Comment 100 by bugdroid1@chromium.org, Sep 23 2015

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/cebc72fa017b6979b0646a75eb7b1baf7ce54b67

commit cebc72fa017b6979b0646a75eb7b1baf7ce54b67
Author: pdr@chromium.org <pdr@chromium.org>
Date: Fri Sep 11 17:31:50 2015

Merge 202060 "Invalidate all non-composited descendants on fixed..."

> Invalidate all non-composited descendants on fixed-position changes
> 
> This patch updates invalidateDisplayItemClientForNonCompositingDescendants
> to use LayoutObject::invalidateDisplayItemClients(...) instead of manually
> calling invalidateDisplayItemClientOnBacking. These two functions are
> deceptively similar but invalidateDisplayItemClients is virtual and
> can perform additional invalidations in some subclasses. One example is
> LayoutInline which invalidates flow-box children in addition to itself.
> 
> This fixes a regression caused by [1] where fixed-pos changes would
> only invalidate LayoutObject non-composited descendants and would forget
> about its inline text friends.
> 
> [1] https://chromium.googlesource.com/chromium/blink/+/0d6c3f0c797a6b26d99487b01aba465caf095a25
> 
> BUG= 509179 
> 
> Review URL: https://codereview.chromium.org/1330993002

TBR=pdr@chromium.org

Review URL: https://codereview.chromium.org/1335223002

git-svn-id: svn://svn.chromium.org/blink/branches/chromium/2490@202148 bbb929c8-8fbe-4397-9dbb-9b2b20218538

[modify] http://crrev.com/cebc72fa017b6979b0646a75eb7b1baf7ce54b67/third_party/WebKit/LayoutTests/TestExpectations
[add] http://crrev.com/cebc72fa017b6979b0646a75eb7b1baf7ce54b67/third_party/WebKit/LayoutTests/paint/invalidation/fixed-position-with-text-expected.html
[add] http://crrev.com/cebc72fa017b6979b0646a75eb7b1baf7ce54b67/third_party/WebKit/LayoutTests/paint/invalidation/fixed-position-with-text.html
[modify] http://crrev.com/cebc72fa017b6979b0646a75eb7b1baf7ce54b67/third_party/WebKit/LayoutTests/platform/mac/fast/forms/button/button-reset-focus-by-mouse-then-keydown-expected.txt
[add] http://crrev.com/cebc72fa017b6979b0646a75eb7b1baf7ce54b67/third_party/WebKit/LayoutTests/platform/mac/fast/forms/submit/submit-appearance-basic-expected.png
[modify] http://crrev.com/cebc72fa017b6979b0646a75eb7b1baf7ce54b67/third_party/WebKit/LayoutTests/platform/mac/fast/forms/submit/submit-focus-by-mouse-then-keydown-expected.txt
[modify] http://crrev.com/cebc72fa017b6979b0646a75eb7b1baf7ce54b67/third_party/WebKit/Source/core/layout/LayoutObject.cpp

Project Member

Comment 101 by bugdroid1@chromium.org, Sep 24 2015

Hi,

I managed to replicate this on other custom website menus and not just word press. I am still having the issue on Chrome in Windows 7. When do you think this be available for Windows Chrome?

Many Thanks
http://www.wdfshare.com
Showing comments 3 - 102 of 102 Older

Sign in to add a comment