Hey all,

We're seeing this in feedback reports as well. Primarily affecting Windows but there's at least one Linux report. Users are running 66.0.3359.117.

Reports w/ Screenshots:
- https://listnr.corp.google.com/report/85353646804
- https://listnr.corp.google.com/report/85353034311
- https://listnr.corp.google.com/report/85352863849
- https://listnr.corp.google.com/report/85352020389

Reports w/o Screenshots:
- https://listnr.corp.google.com/report/85356088864
- https://listnr.corp.google.com/report/85355906330
- https://listnr.corp.google.com/report/85355668087
- https://listnr.corp.google.com/report/85355630031

Community Report:
- https://productforums.google.com/d/msg/chrome/XZylVBBqDM8/l3KCplhnAgAJ

Thanks!

mgoodpickle@, thank you for the report. Can you please provide website urls where you are seeing this issue consistently? and also clear repro steps if possible?

Also please attach "chrome://gpu" info as well.

Thank you!

Same issue here

attached file chrome://gpu

Deleted: chromegpu.txt 99 KB

chromegpu.txt 99 KB View Download

+enne@ because this could be a raster bug.

+piman@, +danakj@ as FYI for triage purposes. 

+kylechar@ in case this is a software compositing bug.

The look like missing tiles with a weird exception in one screenshot where they are too close together?

It looks like something went wrong with ordering barriers/sync tokens.

GL errors:

8024:7580:0422/212354.714:ERROR:gles2_cmd_decoder.cc(18288)] : [.RenderWorker-000002BD49C32320]GL ERROR :GL_INVALID_OPERATION : glCreateAndConsumeTextureCHROMIUM: invalid mailbox name
[8024:7580:0422/212354.718:ERROR:gles2_cmd_decoder.cc(18288)] : [.RenderWorker-000002BD49C32320]GL ERROR :GL_INVALID_OPERATION : glCreateAndConsumeTextureCHROMIUM: invalid mailbox name
[8024:7580:0422/212354.726:ERROR:gles2_cmd_decoder.cc(18288)] : [.DisplayCompositor-00000190302E3000]GL ERROR :GL_INVALID_OPERATION : glCreateAndConsumeTextureCHROMIUM: invalid mailbox name
[8024:7580:0422/212354.727:ERROR:gles2_cmd_decoder.cc(10129)] : [.DisplayCompositor-00000190302E3000]RENDER WARNING: texture bound to texture unit 0 is not renderable. It maybe non-power-of-2 and have incompatible texture filtering.
[8024:7580:0422/212354.744:ERROR:gles2_cmd_decoder.cc(18288)] : [.DisplayCompositor-00000190302E3000]GL ERROR :GL_INVALID_OPERATION : glCreateAndConsumeTextureCHROMIUM: invalid mailbox name
[8024:7580:0422/212354.744:ERROR:gles2_cmd_decoder.cc(10129)] : [.DisplayCompositor-00000190302E3000]RENDER WARNING: texture bound to texture unit 0 is not renderable. It maybe non-power-of-2 and have incompatible texture filtering.
[8024:7580:0422/212354.749:ERROR:gles2_cmd_decoder.cc(18288)] : [.RenderWorker-000002BD49C32320]GL ERROR :GL_INVALID_OPERATION : glCreateAndConsumeTextureCHROMIUM: invalid mailbox name
[8024:7580:0422/212354.752:ERROR:gles2_cmd_decoder.cc(18288)] : [.RenderWorker-000002BD49C32320]GL ERROR :GL_INVALID_OPERATION : glCreateAndConsumeTextureCHROMIUM: invalid mailbox name
[8024:7580:0422/212354.755:ERROR:gles2_cmd_decoder.cc(18288)] : [.DisplayCompositor-00000190302E3000]GL ERROR :GL_INVALID_OPERATION : glCreateAndConsumeTextureCHROMIUM: invalid mailbox name
[8024:7580:0422/212354.755:ERROR:gles2_cmd_decoder.cc(10129)] : [.DisplayCompositor-00000190302E3000]RENDER WARNING: texture bound to texture unit 0 is not renderable. It maybe non-power-of-2 and have incompatible texture filtering.


etc.

danakj@ any chance the ResourceProvider/ResourcePool refactoring changes might be responsible? M66 branched on Apr 13.

I had thought the meaningful stuff is in 67, but here's what we did:


af3170e5f40955165ffea7a5dd0d8032a9e012f5 moves onecopy resource creation to the RasterBufferProvider. It's in 66

d1dd03155abe26c9b1c7bcba580c2b8de406310f removed RasterBufferProvider::OrderingBarrier. It's also in 66.

It's plausible one of these is causing problems. The latter has https://bugs.chromium.org/p/chromium/issues/detail?id=816520 open for thoughts still, and may be related or no?

I haven't seen this reproduce myself on linux yet with gpu compositing and one-copy raster. If you have any thoughts to exacerbate and find the issue I could try help out.

*** Bulk Edit ***
M67 Stable promotion is coming soon. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge into the release branch ASAP. 

If fix is already merged to M67 and nothing else is pending, pls mark the bug as fixed. Thank you.

I can't find anything obviously wrong with the CLs above. I suspected 7f7070dc387269e0901fd4924d0d28fd885e8871, but that landed in 67.

The logs say that the raster worker sees an invalid mailbox, and then the display compositor sees invalid mailbox too. So something's wrong on the first use of the resource, when the GpuBacking is created.

Or could it be a recycled resource?

 Issue 839716  has been merged into this issue.

 Issue 837325  has been merged into this issue.

 Issue 833102  has been merged into this issue.

 Issue 833820  has been merged into this issue.

I'm getting black boxes on Web-pages and when scrolling in a number of web-pages. Also, When I am working on a web-page which contains a flash images. This happens even in the chrome "last pages visited" new tab display.

I'm running Version 66.0.3359.139 (Official Build) (64-bit)

Here are the websites black boxes have appeared this week...

https://www.facebook.com/  4/30/2018

http://www.foxnews.com/entertainment/2018/05/02/cheech-chong-reflect-on-up-in-smoke-success-studio-had-no-idea-what-were-doing.html
5/2/2018

http://www.foxnews.com/     5/2/2018

http://www.foxnews.com/entertainment/2018/05/02/meghan-markles-estranged-half-brother-slams-suits-star-in-letter-to-prince-harry.html
5/03/2018

*** Bulk Edit ***
M67 Stable promotion is coming VERY soon. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge into the release branch ASAP. 

If fix is already merged to M67 and nothing else is pending, pls mark the bug as fixed. Thank you.

Fix has landed on trunk, but it was tagged with the wrong bug: https://chromium-review.googlesource.com/c/chromium/src/+/1041142 (commit hash 2f7fef260cb30489018c513a827cd42556259c15)

Wait on compositor sync token after rescheduling cancelled raster task

Raster tasks can be cancelled between being scheduled and running. When
a resource is used for the first time, we create its texture and mailbox
on the compositor context, and expect the worker context to wait on a
sync token. If the task is cancelled before running, the sync token will
be lost and never waited on.

This CL stores the sync token in GpuBacking::returned_sync_token, and
simplifies the code for passing the sync token to RasterBufferImpl.

Test: RasterBufferProviderTest.WaitOnSyncTokenAfterReschedulingTask
Bug:  836497 
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I4cf9be7909659a6a0bfdca44b9251539dd448d57
Reviewed-on: https://chromium-review.googlesource.com/1041142
Commit-Queue: Sunny Sachanandani <sunnyps@chromium.org>
Reviewed-by: danakj <danakj@chromium.org>
Reviewed-by: Antoine Labour <piman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#555956}

This bug requires manual review: M67 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), govind@(Desktop)

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

Before we approve merge to M67, pls answer followings:

As this is M66 regression, could you pls let us know why this is important to merge to M67?
Is the change well baked/verified in canary and safe to merge to M67?
Is the change having enough automation tests coverage?

> As this is M66 regression, could you pls let us know why this is important to merge to M67?

The bug breaks rendering. Black boxes are a very bad experience for users.

> Is the change well baked/verified in canary and safe to merge to M67?

It has baked in Canary for 3 days, but hasn't been verified.

> Is the change having enough automation tests coverage?

There are unit tests.

Thank you sunnyps@. 

pbommana@, could you pls verify on canary if possible?

mgoodpickle@/ v.ram2694@ or whoever is able to repro, could you pls help us to verify this bug on canary? You can download canary from here: https://www.google.com/chrome/browser/canary.html.

Approving merge to M67 branch 3396 based on comment #31 and per offline chat with sunnyps@, this should be a safe merge.

Thank you Krishna for reaching out to user's for verification,Since we were never able to reproduce the issue any verification here isn't accurate.

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

commit e5ecf7aefddbf4af440a268227ce56f7caed50a6
Author: Sunny Sachanandani <sunnyps@chromium.org>
Date: Mon May 07 22:14:16 2018

[m67 merge] Wait on compositor sync token after rescheduling cancelled raster task

Raster tasks can be cancelled between being scheduled and running. When
a resource is used for the first time, we create its texture and mailbox
on the compositor context, and expect the worker context to wait on a
sync token. If the task is cancelled before running, the sync token will
be lost and never waited on.

This CL stores the sync token in GpuBacking::returned_sync_token, and
simplifies the code for passing the sync token to RasterBufferImpl.

TBR=sunnyps@chromium.org

(cherry picked from commit 2f7fef260cb30489018c513a827cd42556259c15)

Test: RasterBufferProviderTest.WaitOnSyncTokenAfterReschedulingTask
Bug:  836230 
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I4cf9be7909659a6a0bfdca44b9251539dd448d57
Reviewed-on: https://chromium-review.googlesource.com/1041142
Commit-Queue: Sunny Sachanandani <sunnyps@chromium.org>
Reviewed-by: danakj <danakj@chromium.org>
Reviewed-by: Antoine Labour <piman@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#555956}
Reviewed-on: https://chromium-review.googlesource.com/1048140
Reviewed-by: Sunny Sachanandani <sunnyps@chromium.org>
Cr-Commit-Position: refs/branch-heads/3396@{#507}
Cr-Branched-From: 9ef2aa869bc7bc0c089e255d698cca6e47d6b038-refs/heads/master@{#550428}
[modify] https://crrev.com/e5ecf7aefddbf4af440a268227ce56f7caed50a6/cc/raster/gpu_raster_buffer_provider.cc
[modify] https://crrev.com/e5ecf7aefddbf4af440a268227ce56f7caed50a6/cc/raster/gpu_raster_buffer_provider.h
[modify] https://crrev.com/e5ecf7aefddbf4af440a268227ce56f7caed50a6/cc/raster/one_copy_raster_buffer_provider.cc
[modify] https://crrev.com/e5ecf7aefddbf4af440a268227ce56f7caed50a6/cc/raster/one_copy_raster_buffer_provider.h
[modify] https://crrev.com/e5ecf7aefddbf4af440a268227ce56f7caed50a6/cc/raster/raster_buffer_provider_unittest.cc
[modify] https://crrev.com/e5ecf7aefddbf4af440a268227ce56f7caed50a6/cc/resources/resource_pool.h

 Issue 841710  has been merged into this issue.

 Issue 840860  has been merged into this issue.

 Issue 842263  has been merged into this issue.

Why has this issue persisted through development since at least 2015?  The claim is placed that it is fixed, but I expect it is a patch that will flake away again because the overarching algorithm flaw is still in place.

Amateur Hour rush coding is not a way to fix the deeper structural failure.

Read my posted comment for more details suggesting how deep this issue is.

Meanwhile I'm moving to Firefox.

Bug Persists.
:/
Unable to attach jpegs showing bug is alive and well (still exists; persists).

I am using Canary, and haven't experienced the bug there yet. But it does appear on stable build on both Windows 7 and 10, on multitude of computer models,  desktops and laptops.

This bug should be fixed on Chrome Desktop Beta version 67.0.3396.40.  

bozo.stojkovic@ or anyone else  pls test/verify the bug on Beta and update result here. Thank you.

You can download Chrome Beta from - https://www.google.com/chrome/browser/beta.html. 

@steelh...@gmail.com since 2015? I use chrome A LOT and has never had this problem of black spots. I dont know if what I am gonna say is gonna help anything but if I cast  tab to my chromecast and keep browsing on the other tabs, there is a much greater chance that the black squares will appear here and there.

gov...@chromium.org I would love to be able to reproduce it on demand on stable build, so I can do the same thing on beta. But the problem seems to appear randomly, even as I try to do the same things I did when the problem appeared. Can't you guys create some kind of stress test or benchmark and tweak it until it starts reproducing the problem across tests?

 Issue 842469  has been merged into this issue.

 Issue 842390  has been merged into this issue.

@#48 we did write a unit test with the fix of course. But it's hard to be 100% sure that the issue we found/fixed is the only issue happening for users. If you use beta and see that this doesn't happen then that would be helpful information for us, since it does happen on stable on your machine. Thanks

@danakj@chromium.org Of course you wrote a unit test. I just thought there would be some kind of tool or something to try and reproduce the problem. I am just shooting in the dark here trying to help, I guess. Nevermind that.

If it did happen on Beta, I would surely post it here, but I haven't seen it yet.

Thanks for the feedback! We reproduced it but want to be confident that we're reproducing the same things are you are, in case we miss anything.

First time black boxes appear on Chrome 66, while using fullscreen. What's weird is that it only appears on my left screen, fullscreen Chrome on my right screen works fine. Same thing on Chrome 68 (only left screen too), though I didn't reboot the computer to see if it changes anything. 

Deleted: 2018-05-15_17-37-33.png 49.0 KB

	2018-05-15_17-37-33.png 49.0 KB View Download

Deleted: 2018-05-15_17-36-38.png 50.3 KB

	2018-05-15_17-36-38.png 50.3 KB View Download

If you guys want I can install beta and use for the next couple of days and check if this weird problem does not happen anymore. I am still facing this problem daily with the current stable version.

Regarding Comment 46...

Installed 67 Desktop Beta Release and so far have not experienced any more black boxes jumping around. I'd say bug appears to have been resolved in 67 Beta. Thank you so much! :D Happy camper at last!

Comment 44 can be deleted.

I am looking at the long experience. why does the appearance of these boxes only seem to be a problem in Chrome?  

If it may be patched and currently not a problem how can we be assured this will not return?

this goes back several years.

It was a new bug introduced in the compositing code in M66. Bugs like this happen when a synchronization problem occurs between the renderer process and the gpu process, other bugs have happened in the past causing textures to be used incorrectly, and when it happens this is the result. We keep the gpu code in a separate sandbox to make web attacks on the renderer more difficult to escape to the rest of your system.

do the world a favor.

Slow down and test the code on varied hardware. For more than 5 minutes at a time.

Internally.

please.

I fought this and ended up wiping my system because there was no acknowledgement that there was a problem.  dozens of hours because you folks hide problems and hide from the general public.

I don't like the Google way, I have lost all faith in it to the point I have nearly deleted my total identity. 14 years next month.

Restore faith in Google.

Please!

Gmail Team <gmail-noreply@google.com>
	
6/20/04
	
to me

First off, welcome. And thanks for agreeing to help us test Gmail. By now you probably know the key ways in which Gmail differs from traditional webmail services. Searching instead of filing. A free gigabyte of storage. Messages displayed in context as conversations. 

Sorry for your trouble, no one is trying to hide, mistakes can happen. But being respectful is important, so I'm going to close comments on this bug.

 Issue 843670  has been merged into this issue.

 Issue 845284  has been merged into this issue.

 Issue 841086  has been merged into this issue.

 Issue 849012  has been merged into this issue.

Issue 814618 has been merged into this issue.