matt.george888@ if possible can you please provide the URL where you were seeing the issue, Since I navigated through the webpage which you have provided and haven't see any issue, if you can provide below details that would help us in further triage the issue :

1. Specific URL which can exhibit the issue, similar to the one which you have provided in screenshot.
2.  GPU details which can be found under "chrome://gpu" save the page as HTML and share it with us

A quick check of the size of the corrupted area seems to indicate that we are losing / corrupting three software-raster tiles (could be a synchronization issue as well?). Adding additional labels.

Adding some ANGLE folks, as this is windows-only, and might be ANGLE related (although I expect we'll need to wait for an about:gpu dump).

Also adding some more compositing folks.

About:gpu (save as webpage, complete) would definitely be helpful.

I apologize for the delay in getting back to you. I cannot provide the exact URL as they are sub URL's in our secure transportation management software. And it is not a single URL most users run around 8-10 tabs all on different URSL for different functions. What's weird is the black or squiggle screen is not an existing window we have open but one that pops in front of our work then disappears. However it is not a pop up window in the sense it was expected or desired.

Also we have determined if we kill the windows DWM.exe (twice, because it comes back) then users will have much longer time periods sometimes hours versue usually minutes before it happens again. However the issue is only happening in chrome not IE of Firefox. So not sure if that information is helpful or not. 

Thank you for providing more feedback. Adding requester "rbasuvula@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

GPU as requested.

Deleted: gpu.html 50.9 KB

gpu.html 50.9 KB View Download

The about:gpu attached is running SwiftShader. matt.george, is this bug still happening on the machine that you captured the GPU info from?

To follow up a bit more - From the about:gpu, it looks like the machine is being remoted into (via citrix), hence no GPU support. Is this how the machine is being used when the issue reproduces? Or were you remoting in just to capture the about:gpu?

Yes this machine experiences the issue.

Seems likely to be the software compositing backend.

Re #9 - SwiftShader always gets reported when GPU is disabled, but I think it only gets used if we hit WebGL. I doubt this is swiftshader related (we're probably not hitting it in the case pictured above).

In doing some quick testing, I found an issue on MacOS with Software Compositing. Not sure if it's related to this issue (might just be the same issue, with different timings):  crbug.com/735185 

Reply to Comment 10

Yes we use citrix. VDI in a a box. Full OS Windows 7. Every user experiencing the problem is a citrix user.

We're seeing a lot of reports related to this. Enne@, can you take a look? Thanks!

matt.george888: if you have time to try to help us track this down, one thing that would help would be a bisect.  You can use https://www.chromium.org/developers/bisect-builds-py to bisect down to the revision of Chrome that caused this problem.  If this broke in 59, then you could bisect from 454471 (m58) to 474897 (m60), e.g.:

  python tools/bisect-builds.py -a win -g 454471 -b 474897 --use-local-cache

It will give you different revisions of Chrome to try and then you can say whether that revision has the bug, doesn't have the bug, or you don't know and will then download other revisions until it hones in on the revision that has the issue.


I'm not sure that I know of anything specific that has changed, re: software compositing in m59.  59 is rolling out to more users now, so I would expect to see more reports (and repro cases?) if it's a software compositing bug vs a citrix/interaction with citrix bug.  I'd like to let this sit a little bit to see if we can get more actionable bug reports.

 Issue 734883  has been merged into this issue.

Unable to reproduce this issue in citrix Xendesktop 7.9 environment, with windows 10 VDI using chrome #60.0.3112.40.  On navigating to the www.sylectus.com, didn't observe any black boxes on the web page.

@enne comment 19

I don't think we are going to be able to help with the bisecting part. I'm not a programmer and have no experience working with python or the likes. We have verified the issue also happens on our Vmware VDI master images before being deployed to Citrix so it is not dependent on Citrix.

kkaluri@, it sounds like this is intermittent, and may not be restricted to a single page... can you continue testing in Xendesktop on a variety of sites? Thank you!

I have a similar issue. More information and screenshots: https://bugs.chromium.org/p/chromium/issues/detail?id=734883

I can't complete bisection because something is wrong with one of your ZIP files but the partial result is:
C:\Users\colin\chrometest>\Python27\python.exe bisect-builds.py -a win -g 454471 -b 474897 --use-local-cache
Downloading list of known revisions...
Saved revisions 1625-482633 to C:\Users\colin\chrometest\.bisect-builds-cache.json
Downloading revision 463982...
Received 99441065 of 99441065 bytes, 100.00%
Bisecting range [454475 (good), 474889 (bad)], roughly 12 steps left.
Trying revision 463982...
Revision 463982 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b
Downloading revision 459003...
Received 99669953 of 99669953 bytes, 100.00%
Bisecting range [454475 (good), 463982 (bad)], roughly 11 steps left.
Trying revision 459003...
Revision 459003 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g
Downloading revision 461322...
Received 99257367 of 99257367 bytes, 100.00%
Bisecting range [459003 (good), 463982 (bad)], roughly 10 steps left.
Trying revision 461322...
Revision 461322 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g
Downloading revision 462510...
Received 99659936 of 99659936 bytes, 100.00%
Bisecting range [461322 (good), 463982 (bad)], roughly 9 steps left.
Trying revision 462510...
Revision 462510 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g
Downloading revision 463179...
Received 98980782 of 98980782 bytes, 100.00%
Bisecting range [462510 (good), 463982 (bad)], roughly 8 steps left.
Trying revision 463179...
Revision 463179 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g
Downloading revision 463565...
Received 99409207 of 99409207 bytes, 100.00%
Bisecting range [463179 (good), 463982 (bad)], roughly 7 steps left.
Trying revision 463565...
Revision 463565 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g
Downloading revision 463767...
Received 99444312 of 99444312 bytes, 100.00%
Bisecting range [463565 (good), 463982 (bad)], roughly 6 steps left.
Trying revision 463767...
Revision 463767 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g
Downloading revision 463915...
Received 99437815 of 99437815 bytes, 100.00%
Bisecting range [463767 (good), 463982 (bad)], roughly 5 steps left.
Trying revision 463915...
Revision 463915 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b
Downloading revision 463843...
Received 81887232 of 99465667 bytes, 82.33%Exception in thread down_fetch:
Traceback (most recent call last):
  File "C:\Python27\lib\threading.py", line 801, in __bootstrap_inner
    self.run()
  File "C:\Python27\lib\threading.py", line 754, in run
    self.__target(*self.__args, **self.__kwargs)
  File "bisect-builds.py", line 526, in FetchRevision
    urllib.urlretrieve(download_url, filename, ReportHook)
  File "C:\Python27\lib\urllib.py", line 98, in urlretrieve
    return opener.retrieve(url, filename, reporthook, data)
  File "C:\Python27\lib\urllib.py", line 289, in retrieve
    "of %i bytes" % (read, size), result)
ContentTooShortError: retrieval incomplete: got only 81886614 out of 99465667 by
tes

Bisecting range [463767 (good), 463915 (bad)], roughly 4 steps left.
Trying revision 463843...
File is not a zip file
Revision 463843 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: r
Bisecting range [463767 (good), 463915 (bad)], roughly 4 steps left.
Trying revision 463843...
File is not a zip file
Revision 463843 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]:

Hi colin@,

If you hit the bad-zip issue, can you try just replying "u" for unknown, which will skip that revision and keep trying? You've already helped a lot, but going a bit deeper would be really useful.

Thanks!

I was able to download this file by restarting bisect-builds.py with appropriate -g and -b parameters instead of replying "r".

C:\Users\colin\chrometest>\Python27\python.exe bisect-builds.py -a win -g 463767 -b 463915 --use-local-cache
Downloading list of known revisions...
Loaded revisions 1625-482633 from C:\Users\colin\chrometest\.bisect-builds-cache.json
Downloading revision 463843...
Received 99465667 of 99465667 bytes, 100.00%
Bisecting range [463767 (good), 463915 (bad)], roughly 4 steps left.
Trying revision 463843...
Revision 463843 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g
Downloading revision 463880...
Received 99422896 of 99422896 bytes, 100.00%
Bisecting range [463843 (good), 463915 (bad)], roughly 3 steps left.
Trying revision 463880...
Revision 463880 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b
Downloading revision 463855...
Received 99442743 of 99442743 bytes, 100.00%
Bisecting range [463843 (good), 463880 (bad)], roughly 2 steps left.
Trying revision 463855...
Revision 463855 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b
You are probably looking for a change made after 463843 (known good), but no later than 463855 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/aa63f76987632c4cd1f0e985bf420d7f9ffcae2a..810b810269e4329d50c089c26d77f47ea89b61ef

Maybe https://chromium.googlesource.com/chromium/src/+/2040988b1345e6ce738bd03ab7ccd5f4b73a956b

Does that make compositorframes arrive in the browser in a separate channel from sharedmemory stuff such that its racey?

Was off reading code and noticed this which made me think of this bug:

// This interface needs to be associated with the RenderMessageFilter interface
// to prevent running into message ordering issues (CC trying to access a
// shared bitmap before the registration message below made it to the display
// compositor).
interface SharedBitmapManager {

i have a note about this problem which i suffer as well, when enabled "Use hardware acceleration when available" i don't get the problem, but if it disabled the problem return ! try that, then give me your feedback..

This is where mojom::SharedBitmapManager is associated as the comment says: https://cs.chromium.org/chromium/src/content/renderer/render_thread_impl.cc?rcl=d698cc2f6fb72308e7aff05766ba4381a99d09f1&l=679

Probably it needs to be with the CompositorFrameSink's mojo channel instead.

I'm not convinced that this is the cause of the bug but here's the patch that ported SharedBitmapManager to mojo: https://codereview.chromium.org/2717213004

Ohh, I missed #32, Saman and I had the same thought.

This is in 59 but that's going to ship with it, as we caught this too late. We'll target 60 with a fix before it goes to stable.

I am also getting these random black boxes in chrome, happens when browsing normally but on rare occasions. I have a triple monitor setup. Hardware acceleration is disabled. 

The NextAction date has arrived: 2017-07-03

@samans: Friendly ping! Could you please provide any update on this issue as it has been marked as a stable blocker.

Thank You!

SharedBitmap allocation is definitely racey and I can easily reproduce it on my workstation by delaying the browser's IO thread at the right time. It causes artifacts similar to what we have in this bug but not entirely the same, so I can't say with 100% certainty that this is the same bug but it most probably is. I'm prioritizing this bug and I hope to send out a CL soon.

 Issue 738324  has been merged into this issue.

 Issue 738584  has been merged into this issue.

 Issue 739093  has been merged into this issue.

 Issue 739210  has been merged into this issue.

 Issue 739478  has been merged into this issue.

Issue 740087 has been merged into this issue.

I'm seeing quite a few user submitted reports of similar issues.  I've duped ones that I found manually into this bug to try to keep it manageable.

How's the fix coming?

I already have a controversial CL, but we'll probably take another approach. I think the safest, easiest solution which piman proposed is having a sequence number in ClientSharedBitmapManager that we increase after each allocation. We send this number alongside the CompositorFrame and in viz the frame won't be processed until we receive the bitmap with that sequence number. Possibly we could use surface sync and the concept of pending frame to implement this. I'll do my best to implement this as fast as possible. If you also have any other ideas please let us know.

@samans: Friendly ping! Could you please provide any update on this issue as it has been marked as a stable blocker.

Thank You!

I don't know what a 'stable blocker' means but I turned off the hardware
accelerator and that seems to have worked for now - but I haven't used the
computer much so not sure it is a true test.  I will re-contact you if it
returns.

Thanks.

rbasuvula: The fix is under review.

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

commit 9b768545097f64b50cd4bed23a93380b9ccdd195
Author: Saman Sami <samans@chromium.org>
Date: Fri Jul 14 20:42:34 2017

Don't process CompositorFrames until their SharedBitmaps are ready

CompositorFrames and SharedBitmaps' memory handles come from two different
mojo pipes and currently there is no guarantee that for all SharedBitmaps 
referenced by a CompositorFrame are available when it arrives. In this CL
ClientSharedBitmapManager assigns a sequence number to each SharedBitmap
it allocates. These sequence numbers are sent to the browser process along
with the CompositorFrame that references those SharedBitmaps. When a
CompositorFrame arrives, RenderWidgetHostImpl asks from
SharedBitmapAllocationNotifierImpl the latest sequence number from that
renderer known to the browser and if the CompositorFrame references higher
sequence numbers it won't be processed until
SharedBitmapAllocationNotifierImpl notifies RenderWidgetHostImpl through the
SharedBitmapAllocationObserver interface that the necessary SharedBitmaps are
ready.
A few notes:
- This CL is meant to be a quick fix for  crbug.com/734058 . Long term we
would like this logic to be in viz and not content, but that's
substantially more work.
- This CL only fixes the issue for RenderWidgets, which got broken after
crrev.com/463845. Everything else including OffscreenCanvas has always
been broken and remains broken.
- SharedBitmapAllocationNotifier will no longer be associated with
RenderMessageFilter. It used to be associated to preserve ordering with
respect to CompositorFrames, but after crrev.com/463845 CompositorFrames
no longer share a pipe with RenderMessageFilter so there is no point.
As a result SharedBitmapAllocationNotifierImpl now has its own separate
pipe and it lives on the UI thread which is nicer because that's where
the observers (RenderWidgetHostImpls) live and we can avoid doing PostTasks.
The separate pipe also prepares us for an out of process display compositor
because RenderMessageFilter will always be a browser<->renderer pipe and 
being associated with it doesn't make much sense.
- With SharedBitmapAllocationNotifierImpl living on UI thread, I thought
we should be able to get rid of the mutex in ServerSharedBitmapManager,
but it seems like OnMemoryDump is still being called from another thread.
We should investigate whether something can be done about OnMemoryDump
so we can get rid of the lock because it feels very unnecessary now.

BUG= 734058 

Change-Id: I3ba32f1e1cb4fce1589445b2f17e9f9855aa0c40
Reviewed-on: https://chromium-review.googlesource.com/565645
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Reviewed-by: Antoine Labour <piman@chromium.org>
Commit-Queue: Saman Sami <samans@chromium.org>
Cr-Commit-Position: refs/heads/master@{#486875}
[modify] https://crrev.com/9b768545097f64b50cd4bed23a93380b9ccdd195/cc/ipc/cc_param_traits_macros.h
[modify] https://crrev.com/9b768545097f64b50cd4bed23a93380b9ccdd195/cc/ipc/shared_bitmap_allocation_notifier.mojom
[modify] https://crrev.com/9b768545097f64b50cd4bed23a93380b9ccdd195/cc/ipc/struct_traits_unittest.cc
[modify] https://crrev.com/9b768545097f64b50cd4bed23a93380b9ccdd195/cc/ipc/transferable_resource.mojom
[modify] https://crrev.com/9b768545097f64b50cd4bed23a93380b9ccdd195/cc/ipc/transferable_resource_struct_traits.cc
[modify] https://crrev.com/9b768545097f64b50cd4bed23a93380b9ccdd195/cc/ipc/transferable_resource_struct_traits.h
[modify] https://crrev.com/9b768545097f64b50cd4bed23a93380b9ccdd195/cc/resources/resource_provider.cc
[modify] https://crrev.com/9b768545097f64b50cd4bed23a93380b9ccdd195/cc/resources/transferable_resource.cc
[modify] https://crrev.com/9b768545097f64b50cd4bed23a93380b9ccdd195/cc/resources/transferable_resource.h
[modify] https://crrev.com/9b768545097f64b50cd4bed23a93380b9ccdd195/cc/test/test_shared_bitmap_manager.cc
[modify] https://crrev.com/9b768545097f64b50cd4bed23a93380b9ccdd195/components/viz/client/client_shared_bitmap_manager.cc
[modify] https://crrev.com/9b768545097f64b50cd4bed23a93380b9ccdd195/components/viz/client/client_shared_bitmap_manager.h
[modify] https://crrev.com/9b768545097f64b50cd4bed23a93380b9ccdd195/components/viz/common/quads/shared_bitmap.cc
[modify] https://crrev.com/9b768545097f64b50cd4bed23a93380b9ccdd195/components/viz/common/quads/shared_bitmap.h
[modify] https://crrev.com/9b768545097f64b50cd4bed23a93380b9ccdd195/components/viz/service/display_embedder/server_shared_bitmap_manager.cc
[modify] https://crrev.com/9b768545097f64b50cd4bed23a93380b9ccdd195/components/viz/service/display_embedder/shared_bitmap_allocation_notifier_impl.cc
[modify] https://crrev.com/9b768545097f64b50cd4bed23a93380b9ccdd195/components/viz/service/display_embedder/shared_bitmap_allocation_notifier_impl.h
[modify] https://crrev.com/9b768545097f64b50cd4bed23a93380b9ccdd195/content/browser/renderer_host/render_message_filter.cc
[modify] https://crrev.com/9b768545097f64b50cd4bed23a93380b9ccdd195/content/browser/renderer_host/render_message_filter.h
[modify] https://crrev.com/9b768545097f64b50cd4bed23a93380b9ccdd195/content/browser/renderer_host/render_process_host_impl.cc
[modify] https://crrev.com/9b768545097f64b50cd4bed23a93380b9ccdd195/content/browser/renderer_host/render_process_host_impl.h
[modify] https://crrev.com/9b768545097f64b50cd4bed23a93380b9ccdd195/content/browser/renderer_host/render_widget_host_impl.cc
[modify] https://crrev.com/9b768545097f64b50cd4bed23a93380b9ccdd195/content/browser/renderer_host/render_widget_host_impl.h
[modify] https://crrev.com/9b768545097f64b50cd4bed23a93380b9ccdd195/content/common/render_message_filter.mojom
[modify] https://crrev.com/9b768545097f64b50cd4bed23a93380b9ccdd195/content/public/app/mojo/content_browser_manifest.json
[modify] https://crrev.com/9b768545097f64b50cd4bed23a93380b9ccdd195/content/public/browser/render_process_host.h
[modify] https://crrev.com/9b768545097f64b50cd4bed23a93380b9ccdd195/content/public/test/mock_render_process_host.cc
[modify] https://crrev.com/9b768545097f64b50cd4bed23a93380b9ccdd195/content/public/test/mock_render_process_host.h
[modify] https://crrev.com/9b768545097f64b50cd4bed23a93380b9ccdd195/content/public/test/mock_render_thread.cc
[modify] https://crrev.com/9b768545097f64b50cd4bed23a93380b9ccdd195/content/renderer/render_thread_impl.cc

The fix is in the latest canary. If someone who encountered this bug test it it'll be very appreciated. https://www.google.com/chrome/browser/canary.html

61.0.3158.0 works correctly on my HP 250 G4 computer. There are no black rectangles anymore.

I downloaded Canary 61.0.3159.0 and it seems to have corrected the problem.
Not seeing any flickering black boxes or lines in Gmail any more.

We also no longer see the issue in Canary 61.0.3159.0 64-bit

Thank you all for confirming.

This bug requires manual review: We are only 7 days from stable.
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), josafat@(ChromeOS), bustamante@(Desktop)

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

bustamante@ for M60-Merge review.

samans@ this seems like a fairly large fix, and we're only 7 days away from M60 stable. Can you please comment on how safe this merge is overall (safe meaning chances of introducing new regressions or decreasing stability)? I see this has been tested and verified. But looking at the CL in #52, it seems quite large. 

Unfortunately this is the simplest fix we could come up with. There are several CLs depending on the culprit, so reverting isn't very practical. Also a revert will probably cause some panic because it will randomly regress and improve many metrics just like the culprit did when it landed. Overall I would say the CL is pretty safe and worth merging given what some users are experiencing.

Sorry I'm bit confused. Will stable version of v60 have the fixes for the graphics issues?

I think the issue is merging, not reverting. I recommend a merge because this fixes a regression in M59 that affected users not on the accelerated compositing code path.

Yes, not too concerned about reverting, only merging. This seems like a fairly large issue, impacting users and it's also marked as RB-Stable. Approving merge to M60 (branch:3112). We have one more beta cycle this week before stable next week, so would be great to ensure that this merge is safe and not introducing new regressions or stability issues. 

samans@, can you please merge the above change to M60 branch#3112?

Thank you!

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

commit be6cc3d815b615ae254c68c74b5ffc7ab0552d02
Author: Saman Sami <samans@chromium.org>
Date: Wed Jul 19 21:58:02 2017

[Merge to M60] Don't process CompositorFrames until their SharedBitmaps are ready

Merge 9b76854 into branch 3112.

TBR=tsepez@chromium.org,piman@chromium.org

Bug:  734058 
Change-Id: Iabddfab4af11ceaab69a98fd3956a8e40b305cbe
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Reviewed-on: https://chromium-review.googlesource.com/577963
Reviewed-by: Saman Sami <samans@chromium.org>
Reviewed-by: Fady Samuel <fsamuel@chromium.org>
Cr-Commit-Position: refs/branch-heads/3112@{#656}
Cr-Branched-From: b6460e24cf59f429d69de255538d0fc7a425ccf9-refs/heads/master@{#474897}
[modify] https://crrev.com/be6cc3d815b615ae254c68c74b5ffc7ab0552d02/cc/ipc/cc_param_traits_macros.h
[modify] https://crrev.com/be6cc3d815b615ae254c68c74b5ffc7ab0552d02/cc/ipc/struct_traits_unittest.cc
[modify] https://crrev.com/be6cc3d815b615ae254c68c74b5ffc7ab0552d02/cc/ipc/transferable_resource.mojom
[modify] https://crrev.com/be6cc3d815b615ae254c68c74b5ffc7ab0552d02/cc/ipc/transferable_resource_struct_traits.cc
[modify] https://crrev.com/be6cc3d815b615ae254c68c74b5ffc7ab0552d02/cc/ipc/transferable_resource_struct_traits.h
[modify] https://crrev.com/be6cc3d815b615ae254c68c74b5ffc7ab0552d02/cc/resources/resource_provider.cc
[modify] https://crrev.com/be6cc3d815b615ae254c68c74b5ffc7ab0552d02/cc/resources/shared_bitmap.cc
[modify] https://crrev.com/be6cc3d815b615ae254c68c74b5ffc7ab0552d02/cc/resources/shared_bitmap.h
[modify] https://crrev.com/be6cc3d815b615ae254c68c74b5ffc7ab0552d02/cc/resources/transferable_resource.cc
[modify] https://crrev.com/be6cc3d815b615ae254c68c74b5ffc7ab0552d02/cc/resources/transferable_resource.h
[modify] https://crrev.com/be6cc3d815b615ae254c68c74b5ffc7ab0552d02/cc/test/test_shared_bitmap_manager.cc
[modify] https://crrev.com/be6cc3d815b615ae254c68c74b5ffc7ab0552d02/components/viz/display_compositor/host_shared_bitmap_manager.cc
[modify] https://crrev.com/be6cc3d815b615ae254c68c74b5ffc7ab0552d02/components/viz/display_compositor/host_shared_bitmap_manager.h
[modify] https://crrev.com/be6cc3d815b615ae254c68c74b5ffc7ab0552d02/content/browser/renderer_host/render_message_filter.cc
[modify] https://crrev.com/be6cc3d815b615ae254c68c74b5ffc7ab0552d02/content/browser/renderer_host/render_message_filter.h
[modify] https://crrev.com/be6cc3d815b615ae254c68c74b5ffc7ab0552d02/content/browser/renderer_host/render_process_host_impl.cc
[modify] https://crrev.com/be6cc3d815b615ae254c68c74b5ffc7ab0552d02/content/browser/renderer_host/render_process_host_impl.h
[modify] https://crrev.com/be6cc3d815b615ae254c68c74b5ffc7ab0552d02/content/browser/renderer_host/render_widget_host_impl.cc
[modify] https://crrev.com/be6cc3d815b615ae254c68c74b5ffc7ab0552d02/content/browser/renderer_host/render_widget_host_impl.h
[modify] https://crrev.com/be6cc3d815b615ae254c68c74b5ffc7ab0552d02/content/common/render_message_filter.mojom
[modify] https://crrev.com/be6cc3d815b615ae254c68c74b5ffc7ab0552d02/content/public/app/mojo/content_browser_manifest.json
[modify] https://crrev.com/be6cc3d815b615ae254c68c74b5ffc7ab0552d02/content/public/browser/render_process_host.h
[modify] https://crrev.com/be6cc3d815b615ae254c68c74b5ffc7ab0552d02/content/public/test/DEPS
[modify] https://crrev.com/be6cc3d815b615ae254c68c74b5ffc7ab0552d02/content/public/test/mock_render_process_host.cc
[modify] https://crrev.com/be6cc3d815b615ae254c68c74b5ffc7ab0552d02/content/public/test/mock_render_process_host.h
[modify] https://crrev.com/be6cc3d815b615ae254c68c74b5ffc7ab0552d02/content/public/test/mock_render_thread.cc
[modify] https://crrev.com/be6cc3d815b615ae254c68c74b5ffc7ab0552d02/content/renderer/render_thread_impl.cc
[modify] https://crrev.com/be6cc3d815b615ae254c68c74b5ffc7ab0552d02/services/ui/public/cpp/bitmap/child_shared_bitmap_manager.cc
[modify] https://crrev.com/be6cc3d815b615ae254c68c74b5ffc7ab0552d02/services/ui/public/cpp/bitmap/child_shared_bitmap_manager.h

This issue should be fixed in Chrome 60.

This issue is not fixed because it just started for me two days ago (May 2, 2018). I have Chrome build 66.0.3359.139. I just disabled hardware acceleration to see if it will help.

Fixed means in tip of tree, not in the stable channel, sorry.

Okay, no problem. I did disable hardware acceleration and it seemed to solve it for now

"Fixed means in tip of tree, not in the stable channel, sorry."

Is it really the case that this bug marked fixed Jul 19 2017 in not in the official build May 7 2018?

I was just updated to Version 66.0.3359.139 (Official Build) (64-bit) and have started having this issue.

Deleted: 2018-05-07.png 108 KB

	2018-05-07.png 108 KB View Download

#71 You're probably seeing  issue 836230 , which was introduced in M66. It should be fixed on Canary, and on next M67 Beta.

OK thanks,   danakj@chromium.org in comment 70 3 days ago implied that this  issue 734058  wasn't fixed in the stable yet which is what I questioned.  836230 seems to be same symptom as this issue.

Ah sorry I thought you were commenting on 836230 actually.