Same problem here. Are you you also using an ATI / AMD graphics card?

The bug report below which has similar rendering issues narrowed it down to only occurring with the opensource AMD graphics driver, radeon.

https://bugs.chromium.org/p/chromium/issues/detail?id=642095&q=window%20os%3DLinux&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified

Recorded the behavior of this bug. First part shows the bug occurring, second part is a workaround by enabling "Use system title bar and borders".

Deleted: Google Maps.webm 8.3 MB

	Google Maps.webm 8.3 MB View Download

I investigated this a bit from the gnome-shell/mutter side and I'm fairly sure this is a chrome bug.

When maximizing, mutter calls XConfigureWindow with the correct size. When repainting the scene, we call XCompositeNameWindowPixmap and the new pixmap also has the correct size (i.e. what we set in XConfigureWindow).

So, from mutter's POV everything seems fine. It looks like it's chrome that doesn't repaint its X window.

I can reproduce this on an intel haswell but it's not 100% reproducible, I need to maximize and unmaximize a few times in quick succession until it happens.

Screencast of the problem as I see it here  on a uptodate Fedora 24, open radeon driver

Deleted: google-chrome-unstable-55.0.2859.0-1.x86_64-chrome-bug.webm 456 KB

	google-chrome-unstable-55.0.2859.0-1.x86_64-chrome-bug.webm 456 KB View Download

Confirming this behavior: if the Chrome window is, for example, 800x600 in windowed mode, and the "use system title bar and borders" is UNset (thus using chrome title bar), maximizing the window succeeds but only paints an 800x600 region. Tested on 54.0.2840.27 beta (64-bit), Linux. Version 53.0.2785.116 (64-bit) does not exhibit this bug.

If this is the same as https://bugs.chromium.org/p/chromium/issues/detail?id=642095 I have done a bisect there (407803 good, 407808 bad).

https://chromium.googlesource.com/chromium/src/+log/28f548205f0219ffef31a5644412716bf6d8b17c..4479b653205f98f226e7f5d4cf1c6a78897ca97f

Maybe someone else can confirm by testing these two builds:

wget 'https://www.googleapis.com/download/storage/v1/b/chromium-browser-snapshots/o/Linux_x64%2F407803%2Fchrome-linux.zip?alt=media' -O 407803.zip

wget 'https://www.googleapis.com/download/storage/v1/b/chromium-browser-snapshots/o/Linux_x64%2F407808%2Fchrome-linux.zip?alt=media' -O 407808.zip

 Issue 642095  has been merged into this issue.

Based on #8, it looks like the culprit is https://chromium.googlesource.com/chromium/src/+/e5fdc90d17a40a9166a335a0d7c8fd8b2ccf40cd

Assigning to j.isorce

Attaching chrome://gpu for 407803 and 407808, as well as a diff.  It looks like 407808 picked up

+Driver vendor  Mesa
+Driver version 11.2.0

and enabled WebGL, hardware compositing, and other hardware acceleration features.

Deleted: gpu-407803.txt 8.5 KB

gpu-407803.txt 8.5 KB View Download

Deleted: gpu-407808.txt 8.3 KB

gpu-407808.txt 8.3 KB View Download

Deleted: gpu.diff 4.0 KB

gpu.diff 4.0 KB Download

I'm not sure  Issue 642095  should have been merged with this.

For me, the bug is reproducible both with and without --disable-gpu. So, from a bystander POV, that OpenGL version parsing change shouldn't have anything to do with this.

The one thing that works around the bug for me, is to use system titlebar and borders instead of chrome's.

As per comment #10 removing bisect label for now. In case if it's required please feel free to add it back.

tiagoma..., can you try builds 407803 and 407808 linked above and see if 407803 is good and 407808 is bad?  If that is not the case, this is not the same bug and should be un-merged.

Have some detailed steps of how to reproduce in my case at least:

If I delete the Chrome config folders from ~/.config I get back to a state where the rendering is fine. On Arch running Chrome Dev that means I am deleting '~/.config/google-chrome' and '~/.config/google-chrome-unstable'.

At this point maximize is working fine.
Then I can reliably trigger the rendering issue with the following steps:

1) Navigate to 'youtube.com' and play a video (I'm assuming any page with video or other hardware accelerated content will do).
2) Close all Chrome windows
3) Open Chrome
4) Try to maximize the window

Now maximizing has the rendering issue.

Note: you can close and reopen Chrome many times, including navigating to sites without hardware accelerated content such as just going to 'google.com' without triggering the issue. But as soon as you go to a site with hardware accelerated content then the next restart of Chrome the issue is present regardless of what site you are on. Then the only way to stop the issue is to delete the Chrome config folders again.

After the issue has been triggered the following text is added to the '~/.config/google-chrome-unstable/Local State' file:

"gl_renderer_string":"Gallium 0.4 on AMD CYPRESS (DRM 2.45.0 / 4.7.4-1-ARCH, LLVM 3.8.1)","gl_vendor_string":"X.Org","gl_version_string":"4.1 (Core Profile) Mesa 12.0.3"

I attached a screen-cast of this process.

Deleted: Chrome_Bug.webm 7.6 MB

	Chrome_Bug.webm 7.6 MB View Download

I can confirm that from the above-mentioned builds, 407803 is good and 407808 bad on my Fedora 24

I also can confirm build 407803 is good, 407808 is bad based on testing with the steps from comment 15.

Hi, in #11 it shows that the list of GPU driver bug workarounds is different since driver version and vendor is now properly set.

Please try 407808 with previous list, so for example passing --disable_transparent_visuals=1

Please also post the exact diff of workarounds here since I can't see it properly on my mobile. Thx

Adding --disable_transparent_visuals=1 to build 407808 does solve the render size issue when maximized (The issue this bug is about).

However  bug #642095 , which was merged with this issue, can still be triggered by maximizing and un-maximizing quickly (only happens maybe 10% of the time). So you might need to split that back off as a separate bug.

--disable-gpu-compositing seems to fix  bug #642095 .

So a combination of --disable-gpu-compositing and --disable_transparent_visuals=1 solves all issues.

Not sure what changed, but as of Chrome Dev version 55.0.2873.0  bug #642095  seems to be fixed with gpu compositing still on.

To to edit comment #21, only --disable_transparent_visuals is needed now.

 Issue 654246  has been merged into this issue.

The assigned owner "j.isorce@samsung.com" is not able to receive e-mails, please re-triage.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I experienced this in my Wayland session on Ubuntu GNOME.

Hi, I think this issue is obsolete. According to comment #22 it works with flag --disable_transparent_visuals though this flag does not exist anymore. I think this has been reworked by thomasanderson@chromium.org and it is much better now.

I'd be inclined to leave this open.  c#26 was able to repro at the end of Jan.  Chrome stable should have included all of the transparent visual changes by then

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

julien.isorce@, could you verify if the issue is fixed on current stable and close this bug?

It works for me. thomasanderson@ how does it behave for you ?

I was never able to reproduce.