The assignment to the blink component was a mistake.

Can you provide a site where this happens?

Also, can you try temporarily setting chrome://flags/#site-isolation-trial-opt-out to "Opt out" and report if that fixes your problem?  

Hi guys, thanks for the quick response!

Setting chrome://flags/#site-isolation-trial-opt-out to "Opt out" did fixed the issue!

What does that mean? is there something we can do on our end to resolve this without asking our users to change their chrome version?

Thanks, Gilad

Thank you for providing more feedback. Adding the requester to the cc list.

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

Can you check whether the problem still occurs on Chrome 69 when you enable Site Isolation using chrome://flags/#enable-site-per-process?  That will let us confirm whether the bug has been fixed even when Site Isolation is enabled (and we might just need to merge the fix), or if a fix is still needed.

In general, it's hard for us to investigate or verify a fix without a page to test.  If there's any way to share a simplified version of the page that shows the problem, that would help.

That said, this sounds somewhat similar to an out-of-process iframe GPU raster issue we fixed back in  issue 690605 .  Ken, do you know if there's remaining cases where it might be a problem?

I can't think of any likely causes off-hand.

Fady, any thoughts on this?

This is not a known issue. I'd love to get a particular test case so we can better understand the problem.

on it, working on getting you guys one soon

I created a demo page to demonstrate the issue.

1. Go to: https://gilad-solter.github.io/
2. Click on 'Register'
3. Scroll down a bit and click on the 'select sessions' button, a big list will open up and the flickering should start.
4. In the list try to check one of the checkboxes or clicking on the little expand arrow button at the right-bottom corner of each list item.

Yea I'm able to repro. That is super weird. I think the way we are populating the background color might be incorrect. Thanks for the repro.

I tried it on chrome 69.0.3457.2 with the chrome://flags/#enable-site-per-process enabled and the bug reproduced.

Any thing we can do on our side to work around the issue?

Thanks, how can I stay updated on this issue?

gilad@ Thanks for the issue.

Able to reproduce this issue on Windows 10, MacBook Pro Retina 10.13.3 and Ubuntu 17.10 on the reported version 67.0.3396.87 and the latest Canary 69.0.3457.2 as per comment #12.

After enabling the flag #enable-site-per-process and navigating to the site, can observe flickering on the page.
Attached is the screen cast for reference.

This is a Non-Regression issue as this behavior is observed from M-60 chrome builds.

Thanks..

Deleted: 852348-M60.mp4 2.1 MB

	852348-M60.mp4 2.1 MB View Download

Comment 15: Thanks!  The repro URL helps.  You should hear updates as we post them to this bug (and anyone can follow along by starring it).

I can confirm the issue on Windows and Mac Canary 69.0.3457.2 as well, as well as on ChromeOS.  The white areas at the top and bottom when scrolling seem like they might be related to the limited raster area from  issue 690605  (i.e., guttering)-- is that right, Ken?

However, I also see the bigger flickers of white and even dark blue as seen in the video in comment 16.  That seems like a painting issue, as Fady mentions.  Fady, are you able to help look closer, or recommend workarounds?

The NextAction date has arrived: 2018-06-27

I had missed the question in comment 17 -- yes, there is sometimes a delay when scrolling for the raster to catch up, so you see white margins when you scroll quickly, or when you are scrolling slowly but there is a lot of JavaScript running. That is something we'd like to fix but is expected behavior for now.

I can repro this on Mac and Windows, I notice that the flicker occurs pretty much exactly every 5 seconds.

Fady can you think of a timer that might correspond to?

If you are still talking about the url I added here - the 5s timing is related to an animation we have at the top of the screen (a spinning sand-clock).

Hello, I am dealing with something that could be the same problem. I have a page with a lot of heavy content such as animations, videos, and animated gifs. 

When I view the page outside of an iframe, everything renders properly. But when I view the same page inside an iframe, I get flickering content and even missing content. When I flip the "site-isolation-trial-opt-out" flag it fixes the problem.

Here is an example:
1. Here is the normal page outside the iframe: http://view.ceros.com/brett-davidson/pepsi-1/p/1. Notice the white conveyor belt gif working properly.
2. Here is the same page but inside an iframe: https://s3.amazonaws.com/demo.ceros.com/gospotcheck/iframe-chrome-bug.html. The conveyor belt gif often doesn't show up or flickers. Other content struggles as well. For instance, just highlighting text with my mouse cursor causes more flickering.

The issue seems to get worse with more content on the page and with larger screen resolutions.

I'm able to reproduce this in the latest versions of chrome (68.0.3440.75) and chrome canary (70.0.3508.0), but not in firefox or safari.

Thanks for taking a look,
Brett

Also, please note that my example uses a very tall (~10k px) iframe. If the iframe is smaller so that scrolling of the content occurs within the iframe instead of outside of it, the problem goes away. 

For example: https://s3.amazonaws.com/demo.ceros.com/gospotcheck/iframe-chrome-bug-scrolling.html

+gklassen@/piman@ this isn't very fixable without our discussion of fixing oopif over-raster

We should verify though that the viewport we send is correct and that we're doing the right things with it. When we've stopped scrolling, it should catch up reasonably fast, and so wouldn't account for e.g. gifs flickering.

Good catch! This bug was evidently a victim of my mass triage yesterday. Apologies for the oversight!

This is an OOPIF issue. Passing along to jonross.

On ToT for Mac 10.14 I'm seeing the sample in #22 regressed further with a crash

+flackr@ who said they could provide further insight from the animations team, based on the crash stack.

Received signal 6
0   Chromium Framework                  0x000000011a210b9f base::debug::StackTrace::StackTrace(unsigned long) + 31
1   Chromium Framework                  0x000000011a2109f1 base::debug::(anonymous namespace)::StackDumpSignalHandler(int, __siginfo*, void*) + 2385
2   libsystem_platform.dylib            0x00007fff7294cb3d _sigtramp + 29
3   ???                                 0x0000000000000000 0x0 + 0
4   libsystem_c.dylib                   0x00007fff7280b1c9 abort + 127
5   libGPUSupportMercury.dylib          0x00007fff610611c5 gpumCreateComputeContext + 0
6   AppleIntelHD5000GraphicsGLDriver    0x00007fff3dbcb1a4 gpusKillClientExt + 9
7   libGPUSupportMercury.dylib          0x00007fff61062590 gpusSubmitDataBuffers + 165
8   AppleIntelHD5000GraphicsGLDriver    0x00007fff3d780e48 IntelCommandBuffer::getNew(GLDContextRec*) + 48
9   AppleIntelHD5000GraphicsGLDriver    0x00007fff3d780c5f intelSubmitCommands + 178
10  GLEngine                            0x00007fff4f7c5cfb gleUnbindBufferObject + 59
11  GLEngine                            0x00007fff4f7dac60 gleUnbindDeleteHashNameAndObject + 63
12  GLEngine                            0x00007fff4f70f052 glDeleteBuffers_Exec + 2229
13  Chromium Framework                  0x000000011bd513c4 GrGLFunction<void (int, unsigned int const*)>::GrGLFunction<GrGLFunction<void (int, unsigned int const*)> gl::init::(anonymous namespace)::bind_slow<void, int, unsigned int const*>(void (*)(int, unsigned int const*), gl::ProgressReporter*)::'lambda'(int, unsigned int const*)>(void)::'lambda'(void const*, int, unsigned int const*)::__invoke(void const*, int, unsigned int const*) + 20
14  Chromium Framework                  0x000000011a7b7f9b GrGLBuffer::onRelease() + 379
15  Chromium Framework                  0x000000011a6c6558 GrGpuResource::release() + 88
16  Chromium Framework                  0x000000011a6fa473 GrResourceCache::notifyCntReachedZero(GrGpuResource*, unsigned int) + 1251
17  Chromium Framework                  0x000000011a744335 GrMesh* SkArenaAlloc::make<GrMesh, GrPrimitiveType&>(GrPrimitiveType&&&)::'lambda'(char*)::__invoke(char*) + 21
18  Chromium Framework                  0x0000000115dc2cd3 SkArenaAlloc::reset() + 51
19  Chromium Framework                  0x000000011a6c98eb GrOpFlushState::reset() + 171
20  Chromium Framework                  0x000000011a6b8da4 GrDrawingManager::executeOpLists(int, int, GrOpFlushState*) + 1348
21  Chromium Framework                  0x000000011a6b82c8 GrDrawingManager::flush(GrSurfaceProxy*, int, GrBackendSemaphore*) + 2504
22  Chromium Framework                  0x000000011a6b9b70 GrDrawingManager::flushIfNecessary() + 64
23  Chromium Framework                  0x000000011a6e7ad6 GrRenderTargetContext::fillRectToRect(GrClip const&, GrPaint&&, GrAA, SkMatrix const&, SkRect const&, SkRect const&) + 1270
24  Chromium Framework                  0x000000011a80d5b6 SkGpuDevice::drawTextureProducerImpl(GrTextureProducer*, SkRect const&, SkRect const&, SkCanvas::SrcRectConstraint, SkMatrix const&, SkMatrix const&, SkPaint const&) + 1926
25  Chromium Framework                  0x000000011a80ce11 SkGpuDevice::drawTextureProducer(GrTextureProducer*, SkRect const*, SkRect const*, SkCanvas::SrcRectConstraint, SkMatrix const&, SkPaint const&, bool) + 801
26  Chromium Framework                  0x000000011a80c3fe SkGpuDevice::drawPinnedTextureProxy(sk_sp<GrTextureProxy>, unsigned int, SkColorSpace*, SkAlphaType, SkRect const*, SkRect const*, SkCanvas::SrcRectConstraint, SkMatrix const&, SkPaint const&) + 174
27  Chromium Framework                  0x000000011a80846d SkGpuDevice::drawImageRect(SkImage const*, SkRect const*, SkRect const&, SkPaint const&, SkCanvas::SrcRectConstraint) + 477
28  Chromium Framework                  0x0000000115d8d3b4 SkCanvas::onDrawImageRect(SkImage const*, SkRect const*, SkRect const&, SkPaint const*, SkCanvas::SrcRectConstraint) + 708
29  Chromium Framework                  0x0000000115d894d9 SkCanvas::drawImageRect(SkImage const*, SkRect const&, SkRect const&, SkPaint const*, SkCanvas::SrcRectConstraint) + 377
30  Chromium Framework                  0x0000000115da02e3 SkColorSpaceXformCanvas::onDrawImageRect(SkImage const*, SkRect const*, SkRect const&, SkPaint const*, SkCanvas::SrcRectConstraint) + 307
31  Chromium Framework                  0x0000000115d894d9 SkCanvas::drawImageRect(SkImage const*, SkRect const&, SkRect const&, SkPaint const*, SkCanvas::SrcRectConstraint) + 377
32  Chromium Framework                  0x000000011aabec51 cc::DrawImageRectOp::RasterWithFlags(cc::DrawImageRectOp const*, cc::PaintFlags const*, SkCanvas*, cc::PlaybackParams const&) + 881
33  Chromium Framework                  0x000000011aac4ab6 _ZN2cc3$_98__invokeEPKNS_7PaintOpEP8SkCanvasRKNS_14PlaybackParamsE + 118
34  Chromium Framework                  0x000000011c16b75a gpu::raster::RasterDecoderImpl::DoRasterCHROMIUM(unsigned int, unsigned int, long, unsigned int, unsigned int, long) + 1322
35  Chromium Framework                  0x000000011c1615be gpu::raster::RasterDecoderImpl::HandleRasterCHROMIUM(unsigned int, void const volatile*) + 94
36  Chromium Framework                  0x000000011c166c12 gpu::error::Error gpu::raster::RasterDecoderImpl::DoCommandsImpl<false>(unsigned int, void const volatile*, int, int*) + 514
37  Chromium Framework                  0x000000011bd3d479 gpu::CommandBufferService::Flush(int, gpu::AsyncAPIInterface*) + 537
38  Chromium Framework                  0x000000011c281cb6 gpu::CommandBufferStub::OnAsyncFlush(int, unsigned int) + 358
39  Chromium Framework                  0x000000011c281aa5 bool IPC::MessageT<GpuCommandBufferMsg_AsyncFlush_Meta, std::__1::tuple<int, unsigned int>, void>::Dispatch<gpu::CommandBufferStub, gpu::CommandBufferStub, void, void (gpu::CommandBufferStub::*)(int, unsigned int)>(IPC::Message const*, gpu::CommandBufferStub*, gpu::CommandBufferStub*, void*, void (gpu::CommandBufferStub::*)(int, unsigned int)) + 101
40  Chromium Framework                  0x000000011c2807c5 gpu::CommandBufferStub::OnMessageReceived(IPC::Message const&) + 1301
41  Chromium Framework                  0x000000011ab0fee2 IPC::MessageRouter::RouteMessage(IPC::Message const&) + 146
42  Chromium Framework                  0x000000011c28e8b4 gpu::GpuChannel::HandleMessageHelper(IPC::Message const&) + 164
43  Chromium Framework                  0x000000011c28c344 gpu::GpuChannel::HandleMessage(IPC::Message const&) + 628
44  Chromium Framework                  0x000000011c28f9a0 base::internal::Invoker<base::internal::BindState<void (gpu::GpuChannel::*)(IPC::Message const&), base::WeakPtr<gpu::GpuChannel>, IPC::Message>, void ()>::RunOnce(base::internal::BindStateBase*) + 192
45  Chromium Framework                  0x000000011bd443ee gpu::Scheduler::RunNextTask() + 1182
46  Chromium Framework                  0x000000011bd47507 base::internal::Invoker<base::internal::BindState<void (gpu::Scheduler::*)(), base::WeakPtr<gpu::Scheduler> >, void ()>::Run(base::internal::BindStateBase*) + 183
47  Chromium Framework                  0x000000011a0f96f1 base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*) + 305
48  Chromium Framework                  0x000000011a12a5b0 base::MessageLoopImpl::RunTask(base::PendingTask*) + 272
49  Chromium Framework                  0x000000011a12ac23 base::MessageLoopImpl::DoWork() + 387
50  Chromium Framework                  0x000000011a12ccba base::MessagePumpCFRunLoopBase::RunWork() + 42
51  Chromium Framework                  0x000000011a112e1a base::mac::CallWithEHFrame(void () block_pointer) + 10
52  Chromium Framework                  0x000000011a12c5df base::MessagePumpCFRunLoopBase::RunWorkSource(void*) + 63
53  CoreFoundation                      0x00007fff4559f155 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
54  CoreFoundation                      0x00007fff4559f0fb __CFRunLoopDoSource0 + 108
55  CoreFoundation                      0x00007fff45582b95 __CFRunLoopDoSources0 + 195
56  CoreFoundation                      0x00007fff4558213e __CFRunLoopRun + 1219
57  CoreFoundation                      0x00007fff45581a28 CFRunLoopRunSpecific + 463
58  Foundation                          0x00007fff478e83ba -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 280
59  Chromium Framework                  0x000000011a12d520 base::MessagePumpNSRunLoop::DoRun(base::MessagePump::Delegate*) + 128
60  Chromium Framework                  0x000000011a12c01e base::MessagePumpCFRunLoopBase::Run(base::MessagePump::Delegate*) + 110
61  Chromium Framework                  0x000000011a12a158 base::MessageLoopImpl::Run(bool) + 136
62  Chromium Framework                  0x000000011a1652e9 base::RunLoop::Run() + 249
63  Chromium Framework                  0x00000001202421e0 content::GpuMain(content::MainFunctionParams const&) + 1424
64  Chromium Framework                  0x0000000119adc157 content::ContentMainRunnerImpl::Run(bool) + 407
65  Chromium Framework                  0x000000011d0b862e service_manager::Main(service_manager::MainParams const&) + 3166
66  Chromium Framework                  0x0000000119adb324 content::ContentMain(content::ContentMainParams const&) + 68
67  Chromium Framework                  0x0000000115d1529f ChromeMain + 175
68  Chromium Helper                     0x000000010639c7ae main + 494
69  libdyld.dylib                       0x00007fff7276308d start + 1

+kylechar@ FYI with regards to Mac + OOP-D + Site Isolation

Looks like either a driver issue or something bad that Skia gives to the driver.

GrGLBuffer::onRelease is the #1 macOS GPU crasher lately -- issue 906453. Not an OOP-D issue.

Some further checks of features using the second link in #22 (the iframe test case)

70.0.3538.110 (Official Build): no crash, no flash. However enable-site-per-process is disabled

71 Beta: regardless of OOP-D being on/off the animation is demonstrating the flashing issue described in #22

ToT: Crashes when enable-oop-rasterization=true
     With OOP-R off, same flashing issue as in 71 Beta, regardless of OOP-D.
     When I set site-isolation-trial-opt-out=disabled, to turn off site isolation, then the animation resumes smoothly

So we have two issues here. OOP-R crash, and site isolation breaking web animations.

Hey kenrb@

It appears that this bug is tied to site-isolation. As it occurs regardless of OOP-R/OOP-D.

Could you help triage this? Or point me to a spot to investigate this further?

Hi Guys,

I see that this issue is back and that chrome 71 is shipped with the #site-isolation-trial-opt-out flag on by default.
This causes the bug to reproduce.

Any chance there is a workaround for this issue?  
Something we can do on our side to fix the flickering?
I work for a B2B2C company so I can't ask my client's users to turn the flag off...

An update from our debug sessions while trying to workaround the issue.

 - The flickering happens only when there are a lot of elements in the iFrame.
 - The flickering is related to animations. We removed all css transitions from the UI and the issue disappeared.