Background tabs may not have a copy of the content in the browser process at all to copy, as we evict content from background tabs eventually.

There was some work on this area by siva.gunturi@samsung.com in the past, but it fell off. Here's an example:

https://bugs.chromium.org/p/chromium/issues/detail?id=472457#c10

> Internally, cc orders the surface to redraw when it becomes reattached to the webview.

Are you saying the background tab is no longer in the layer tree? Then the compositor def can't schedule a copy.

Why the blink labels on the bug? Screenshotting is all done in the browser. Is this windows only? If something changed, perhaps you can bisect to that?

https://chromium.googlesource.com/chromium/src/+log/1ee44ea93271409b790999e882d05c0666a89850..a0f4b5051a2ef87f7de7cb469fe87d781cc0ab35

The scenario was:

load vg.no , open new tab, check if the speed dial that appeared has a thumbnail image.

396779 (known good) 397176 (first known bad)

cc-related code integrated in this range was:

https://codereview.chromium.org/1895873006
https://codereview.chromium.org/2017263002
https://codereview.chromium.org/1998393002
https://codereview.chromium.org/2018263002
https://codereview.chromium.org/2025893003
https://codereview.chromium.org/2023973002
https://codereview.chromium.org/2022203003
https://codereview.chromium.org/2021433005
https://codereview.chromium.org/2018833002
https://codereview.chromium.org/2019833002
https://codereview.chromium.org/2020993004

ajuma's https://codereview.chromium.org/2017263002 certainly looks the most related to copy requests.

mboc@, can you say a bit more about how to repro this? For the steps given in 4, do I need to wait for the page to finish loading? Also, does this repro with the Chromium new tab page (not sure if the reference to 'speed dial' meant that this only repro'd in Opera)?

ajuma@ :

1) Clean the profile
2) Open vg.no in a new tab
3) Wait until it loads
4) Open a new tab, a new 'speed dial', or 'top site' as Chromium calls it should appear.

In the faulty case graphics for the top site will be missing.

Mind that switching back to the vg.no tab will cause a buffer swap and the image will be visible. But it used to be visible immediately (so the cc allowed a swap in the background).

Deleted: good.png 137 KB

	good.png 137 KB View Download

Deleted: bad.png 113 KB

	bad.png 113 KB View Download

The layer with the copy request is getting removed from the layer tree before the next commit (actually, it's added/removed multiple times between the copy request being added and the commit, but the important thing here is that it's not in the tree at commit time). It's only added back once the tab is made visible again, and at that point the copy request gets committed.

I bisected this to https://codereview.chromium.org/2018333002. The changes to NativeWidgetPrivate::ReparentNativeView are likely the cause.

Yes. That would affect this. I will revert this part of the patch.

> > Internally, cc orders the surface to redraw when it becomes reattached to the webview.
> 
> Are you saying the background tab is no longer in the layer tree? Then the compositor
> def can't schedule a copy.

@danakj: Would it be possible to still do a copy of a detached layer/surface by adding something new to, say, CompositorObserver?

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

commit 31cbd8a0d0760694e913ed8de1f33bc8a416e84b
Author: sadrul <sadrul@chromium.org>
Date: Thu Jun 23 16:44:50 2016

views: Restore to old behaviour of Widget::ReparentNativeView().

Restore the previous behaviour of Widget::ReparentNativeView() of parenting the
window to the root-window, instead of detaching it from the window tree. This is
necessary since copy-requests on the window cannot be performed when the window
is detached from the layer-tree. This breaks, among other things, capturing
thumbnail of a page when it is backgrounded.

BUG= 621018 , 616399

Review-Url: https://codereview.chromium.org/2094513003
Cr-Commit-Position: refs/heads/master@{#401629}

[modify] https://crrev.com/31cbd8a0d0760694e913ed8de1f33bc8a416e84b/ui/views/controls/native/native_view_host_aura_unittest.cc
[modify] https://crrev.com/31cbd8a0d0760694e913ed8de1f33bc8a416e84b/ui/views/widget/native_widget_aura.cc

sadrul: There's no way to do a copy of a detached layer right now.  Copy requests happen in a DirectRenderer as a part of drawing a frame.  If the layer isn't attached, its quads don't become part of the frame, so never get drawn.

If you want to add a copy request for a hidden layer, I think the best approach is to keep it attached but invisible, via ui::Layer::SetVisible.  Does that sort of approach work for you?

Yep, that's what we used to do, and doing now again after the revert in https://bugs.chromium.org/p/chromium/issues/detail?id=621018#c13

> @danakj: Would it be possible to still do a copy of a detached layer/surface by adding something new to, say, CompositorObserver?

As enne said, if its not in a layer tree, then its not in a compositor for the compositor to do the draw/copy of it.

Android did have a second off-screen compositor that they use for readbacks of things not in the tree. That's an option. But now that copies can be done on hidden layers they just leave them in the tree, which does seem probably simpler maybe.

This should be working again after the revert in #13. Marking as fixed.