In theory this should work in mushrome, but it currently doesn't. Need to investigate why.

I'll fix a wiring issue, but after that CopyOutputRequest is served no data and we crash. Here's the stack as to how CopyOutputRequest ends up with nothing:
#0  cc::CopyOutputRequest::SendResult (this=0x3754afe9140, result=std::unique_ptr<cc::CopyOutputResult> containing 0x37544b1aa70)
    at ../../cc/output/copy_output_request.cc:34
#1  0x00007f10190c5a93 in cc::CopyOutputRequest::~CopyOutputRequest (this=0x3754afe9140) at ../../cc/output/copy_output_request.cc:28
#2  0x00007f101906367b in std::default_delete<cc::CopyOutputRequest>::operator() (this=0x3754b0b4560, __ptr=0x3754afe9140)
    at ../../build/linux/debian_jessie_amd64-sysroot/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/unique_ptr.h:67
#3  0x00007f10190635f3 in std::unique_ptr<cc::CopyOutputRequest, std::default_delete<cc::CopyOutputRequest> >::~unique_ptr (this=0x3754b0b4560)
    at ../../build/linux/debian_jessie_amd64-sysroot/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/unique_ptr.h:184
#4  0x00007f10190635a5 in std::_Destroy<std::unique_ptr<cc::CopyOutputRequest, std::default_delete<cc::CopyOutputRequest> > > (__pointer=0x3754b0b4560)
    at ../../build/linux/debian_jessie_amd64-sysroot/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/stl_construct.h:93
#5  0x00007f101906356f in std::_Destroy_aux<false>::__destroy<std::unique_ptr<cc::CopyOutputRequest, std::default_delete<cc::CopyOutputRequest> >*> (
    __first=0x3754b0b4560, __last=0x3754b0b4568)
    at ../../build/linux/debian_jessie_amd64-sysroot/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/stl_construct.h:103
#6  0x00007f101906352d in std::_Destroy<std::unique_ptr<cc::CopyOutputRequest, std::default_delete<cc::CopyOutputRequest> >*> (__first=0x3754b0b4560,
    __last=0x3754b0b4568) at ../../build/linux/debian_jessie_amd64-sysroot/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/stl_construct.h:126
#7  0x00007f10190634c1 in std::_Destroy<std::unique_ptr<cc::CopyOutputRequest, std::default_delete<cc::CopyOutputRequest> >*, std::unique_ptr<cc::CopyOutputRequest\
, std::default_delete<cc::CopyOutputRequest> > > (__first=0x3754b0b4560, __last=0x3754b0b4568)
    at ../../build/linux/debian_jessie_amd64-sysroot/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/stl_construct.h:151
#8  0x00007f101906348e in std::__cxx1998::vector<std::unique_ptr<cc::CopyOutputRequest, std::default_delete<cc::CopyOutputRequest> >, std::allocator<std::unique_pt\
r<cc::CopyOutputRequest, std::default_delete<cc::CopyOutputRequest> > > >::~vector (this=0x37547c60a20)
   at ../../build/linux/debian_jessie_amd64-sysroot/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/stl_vector.h:415
#9  0x00007f101905f7af in std::__debug::vector<std::unique_ptr<cc::CopyOutputRequest, std::default_delete<cc::CopyOutputRequest> >, std::allocator<std::unique_ptr<\
cc::CopyOutputRequest, std::default_delete<cc::CopyOutputRequest> > > >::~vector (this=0x37547c60a20)
    at ../../build/linux/debian_jessie_amd64-sysroot/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/debug/vector:144
#10 0x00007f101914c5db in cc::RenderPass::~RenderPass (this=0x37547c608e0) at ../../cc/quads/render_pass.cc:91
#11 0x00007f101909431b in std::default_delete<cc::RenderPass>::operator() (this=0x37549aed2c8, __ptr=0x37547c608e0)
    at ../../build/linux/debian_jessie_amd64-sysroot/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/unique_ptr.h:67
#12 0x00007f1019093a63 in std::unique_ptr<cc::RenderPass, std::default_delete<cc::RenderPass> >::~unique_ptr (this=0x37549aed2c8)
    at ../../build/linux/debian_jessie_amd64-sysroot/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/unique_ptr.h:184
#13 0x00007f10190c3765 in std::_Destroy<std::unique_ptr<cc::RenderPass, std::default_delete<cc::RenderPass> > > (__pointer=0x37549aed2c8)
    at ../../build/linux/debian_jessie_amd64-sysroot/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/stl_construct.h:93
#14 0x00007f10190c372f in std::_Destroy_aux<false>::__destroy<std::unique_ptr<cc::RenderPass, std::default_delete<cc::RenderPass> >*> (__first=0x37549aed2c8,
    __last=0x37549aed2d8) at ../../build/linux/debian_jessie_amd64-sysroot/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/stl_construct.h:103
#15 0x00007f10190c36ed in std::_Destroy<std::unique_ptr<cc::RenderPass, std::default_delete<cc::RenderPass> >*> (__first=0x37549aed2c0, __last=0x37549aed2d8)
    at ../../build/linux/debian_jessie_amd64-sysroot/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/stl_construct.h:126
#16 0x00007f10190c3681 in std::_Destroy<std::unique_ptr<cc::RenderPass, std::default_delete<cc::RenderPass> >*, std::unique_ptr<cc::RenderPass, std::default_delete\
<cc::RenderPass> > > (__first=0x37549aed2c0, __last=0x37549aed2d8)
    at ../../build/linux/debian_jessie_amd64-sysroot/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/stl_construct.h:151
#17 0x00007f10190c3eae in std::__cxx1998::vector<std::unique_ptr<cc::RenderPass, std::default_delete<cc::RenderPass> >, std::allocator<std::unique_ptr<cc::RenderPa\
ss, std::default_delete<cc::RenderPass> > > >::~vector (this=0x7fffc72c1df0)
    at ../../build/linux/debian_jessie_amd64-sysroot/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/stl_vector.h:415
#18 0x00007f10190c328f in std::__debug::vector<std::unique_ptr<cc::RenderPass, std::default_delete<cc::RenderPass> >, std::allocator<std::unique_ptr<cc::RenderPass\
, std::default_delete<cc::RenderPass> > > >::~vector (this=0x7fffc72c1df0)
    at ../../build/linux/debian_jessie_amd64-sysroot/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/debug/vector:144
#19 0x00007f10190c2fd5 in cc::CompositorFrame::~CompositorFrame (this=0x7fffc72c1c60) at ../../cc/output/compositor_frame.cc:13
#20 0x00007f10170917a9 in viz::ClientLayerTreeFrameSink::SubmitCompositorFrame (this=0x375458803a0, frame=...)
    at ../../components/viz/client/client_layer_tree_frame_sink.cc:119
#21 0x00007f10192daf2d in cc::LayerTreeHostImpl::DrawLayers (this=0x37544d73020, frame=0x7fffc72c3540) at ../../cc/trees/layer_tree_host_impl.cc:1782
#22 0x00007f101939b2b3 in cc::SingleThreadProxy::DoComposite (this=0x37544f39640, frame=0x7fffc72c3540) at ../../cc/trees/single_thread_proxy.cc:592
#23 0x00007f101939c251 in cc::SingleThreadProxy::ScheduledActionDrawIfPossible (this=0x37544f39640) at ../../cc/trees/single_thread_proxy.cc:760
#24 0x00007f10191e3776 in cc::Scheduler::DrawIfPossible (this=0x37545029360) at ../../cc/scheduler/scheduler.cc:568
#25 0x00007f10191df1ac in cc::Scheduler::ProcessScheduledActions (this=0x37545029360) at ../../cc/scheduler/scheduler.cc:661
#26 0x00007f10191deda2 in cc::Scheduler::OnBeginImplFrameDeadline (this=0x37545029360) at ../../cc/scheduler/scheduler.cc:556

+fsamuel, +sadrul. Any suggestions?

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

commit 838caa2dc11161cb9054e06819e636254cc58ae4
Author: Scott Violet <sky@chromium.org>
Date: Wed Jul 26 21:14:20 2017

chromeos: gets TakeScreenshot() working* for mushrome

* - by working I mean crashing in a different location. This change at
    least gets us past the first crash.

BUG= 706246 
TEST=none
R=jamescook@chromium.org

Change-Id: I1d16a53af4de3201da4f037f50565527b9bdbad4
Reviewed-on: https://chromium-review.googlesource.com/587332
Reviewed-by: James Cook <jamescook@chromium.org>
Commit-Queue: Scott Violet <sky@chromium.org>
Cr-Commit-Position: refs/heads/master@{#489757}
[modify] https://crrev.com/838caa2dc11161cb9054e06819e636254cc58ae4/chrome/browser/ui/browser_commands_chromeos.cc

So CopyOutputRequest's destructor will ensure that the passed in callbacks are always run, even if no frame was ever submitted. So the destructor passes in an empty bitmap.

The two places where we call CopyOutputRequest::SendBitmapResult() are //cc/output/software_renderer.cc and //components/viz/service/display/gl_renderer.cc--neither of these appear to be called inside of the ash window manager, which instead is going through the mojo-ish ClientLayerTreeFrameSink, which is taking the CompositorFrame that owns the CopyOutputRequest, but isn't acting on it.

Fady, you last touched the CopyOuptutRequets code, though it looks like it was a file move. Do you know anything about what's supposed to happen on the mojo client side for readback, and which class is supposed to be responsible for submitting a bitmap to requestors?

Reassigning to miu@ who is making major changes to copy requests.

IIUC, y'all have found plumbing that was started (new mojo APIs introduced) but impl on the VIZ side has not been put in-place yet. The snapshot functionality is heavily dependent on my current work for tab capture (changes to copy requests and how they are executed).

From the stack trace, it looks like the copy requests are not being taken from the RenderPass and executed. Given this is for a whole-desktop screenshot, my guess is this might be the root RenderPass, and I'm not sure if there's any impl to transfer the copy request to the Surface containing its Layer at any point.

sky: CrOS screenshots seem to work now. At least, I ran a target_os="chromeos" build locally, hit CTRL-F5 and got a screenshot. It works whether I run `chrome` or `chrome --mus`. Assigning back to you for feedback: Can we resolve this?

This bug was created before --mus no longer implied viz. --mash will run with mus and viz. I suspect if you run with --mash this won't work. I'm passing back to you, but feel free to kick my way if appropriate.

Hmm...I can't tell. It looks like the shell_delegate_mus.cc plumbing is missing. Is there some way to activate the ScreenshotController otherwise?

When I run `chrome --mash` and try the CTRL-F5 or CTRL-SHIFT-F5, I get these log entries:

[68863:68863:0125/144052.644743:ERROR:shell_delegate_mus.cc(30)] Not implemented reached in virtual void ash::(anonymous namespace)::ScreenshotDelegateMash::HandleTakeScreenshotForAllRootWindows()

[68863:68863:0125/144105.292673:ERROR:shell_delegate_mus.cc(33)] Not implemented reached in virtual void ash::(anonymous namespace)::ScreenshotDelegateMash::HandleTakePartialScreenshot(aura::Window *, const gfx::Rect &)

To clarify something: I can't take on owning the necessary shell changes to make screenshots work (I'm too oversubscribed). But, I'm happy to work on getting the CopyOutputRequests issued to the compositor by ScreenshotController working. :)

miu, that is fair enough. If you think everything is in place to make this work we can take over the rest.

Ah! I took a closer look at the ScreenshotController code. Deep in the implementation, it eventually requests the snapshot using src/ui/snapshot/* routines. These take the window's Layer and add a CopyOutputRequest to it.

So, I ran CrOS on my Linux desktop with `chrome --enable-feature=VizDisplayCompositor` and screenshots worked! IIUC, that means the CopyOutputRequests that are being issued to the desktop's Layer *do* make their way out of the browser process and over to the VIZ process for execution. This is news to me, since it's on our task list to make that work. Maybe it was already done by someone else? FWIW, I'll dig further and confirm for sure before removing the item from our task list.

Anyway, yes, you guys should be able to take over from here. :)

Whoops! Cancel that last comment!

I used --enable-feature=... instead of --enable-features=... (WITH AN "s" at the end). And now, when I run with the correct spelling, screenshots do fail:

[86284:86284:0125/155306.095664:ERROR:screenshot_grabber.cc(216)] Failed to grab the window screenshot for 0,0 1918x710
[86284:86284:0125/155311.956448:ERROR:screenshot_grabber.cc(211)] Failed to grab the window screenshot

So, it seems I really do have some work to do on CopyOutputRequests. Regardless, it shouldn't block you guys, on the UI side of things: Instead of the NOTIMPLEMENTED log message, the UI should at least pop-up a dialog in the lower-right corner saying "screen shot failed" when you hit CTRL-F5.

On the UI side of things, this is large enough that I'm going to write a small work overview. The following is my current understanding:

# ui::ScreenshotGrabber (`//ui/snapshot/screenshot_grabber.cc`)

- File writing is assumed to be part of ScreenshotGrabber's responsibilities.

- It shouldn't though. It should vend png data and the parts which interact
  with files should be in the caller.
  
# ChromeScreenshotGrabber (`//c/b/u/ash/chrome_screenshot_grabber.cc`)

- Has-a ui::ScreenshotGrabber, which it passes desired file names, and passes
  back actual paths where PNG files were written / err codes in response.

- However, it has a bunch of other responsibilities that aren't directly
  related to dealing with screenshots:
  
    - Communicating with Google Drive.
    
    - Calculating file names for the resulting screenshots.
    
    - Managing notifications regarding whether the screenshot succeeded or failed.
    
    - Creating a utility process to read back the PNG file that was written in
      ui::ScreenshotGrabber so that it can display the screenshot in the
      notification.

    - Copying the image to the clipboard.

# ash::ScreenshotDelegateMash (`//ash/shell_delegate_mus.cc`)

- Stub class which is an implementation of `//ash/screenshot_delegate.h`. As
  this is in the window manager, theoretically this should work purely with the
  image data and not touch files at all. It certainly shouldn't have a Google
  Drive dependency.

# Plan

- Part 1 is to simplify the ScreenGrabber interface so that it doesn't deal
  with files. (Rational: it's doing too many things and we don't want file
  handling in the window manager.)
  
- Part 2 is to separate ChromeScreenshotGrabber into a part that uses a
  ScreenshotGrabber to grab windows, and a part that does everything else that
  ScreenshotGrabber currently does, including assigning file names. (Rational:
  in mash mode, we will still need to deal with Google Drive and we don't want
  that in the window manager on Drive.)
  
- Part 3 is to get ScreenshotDelegateMash to use ScreenGrabber, possibly using
  the first part separated from part 2. Get a mojo interface that then sends
  the raw data to a client provided by chrome which then passes it to the
  second separated component from part 2.

FYI--I've got a code change up for review that allows CopyOutputRequests made on Layers to work with VIZ enabled. Links, and other tracking in  bug 806375 .

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

commit 685b3cd46a695f860617f84024bc3ac83e4d2d27
Author: Elliot Glaysher <erg@chromium.org>
Date: Thu Feb 01 23:17:55 2018

Remove file handling from ScreenshotGrabber.

This is the first patch in a series to make screenshots work in
mash. This first step is simplifying ui::ScreenshotGrabber into a
component that can be used without the filesystem. This moves file
writing to the chrome layer, switches to callbacks, and starts
separating ChromeScreenshotGrabber into the part that initiates a
screenshot (will be replaced with an ash side delegate that communicates
over mojo) and the part that accepts the data and writes it to the
filesystem (which will continue to exist and stay in chrome).

Change-Id: Ic2370e0d4426f51ffd09af8920304b98b8ebde0e
Bug:  706246 
Reviewed-on: https://chromium-review.googlesource.com/894882
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Elliot Glaysher <erg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#533848}
[modify] https://crrev.com/685b3cd46a695f860617f84024bc3ac83e4d2d27/chrome/browser/policy/policy_browsertest.cc
[modify] https://crrev.com/685b3cd46a695f860617f84024bc3ac83e4d2d27/chrome/browser/ui/BUILD.gn
[modify] https://crrev.com/685b3cd46a695f860617f84024bc3ac83e4d2d27/chrome/browser/ui/ash/chrome_screenshot_grabber.cc
[modify] https://crrev.com/685b3cd46a695f860617f84024bc3ac83e4d2d27/chrome/browser/ui/ash/chrome_screenshot_grabber.h
[modify] https://crrev.com/685b3cd46a695f860617f84024bc3ac83e4d2d27/chrome/browser/ui/ash/chrome_screenshot_grabber_browsertest.cc
[add] https://crrev.com/685b3cd46a695f860617f84024bc3ac83e4d2d27/chrome/browser/ui/ash/chrome_screenshot_grabber_test_observer.h
[modify] https://crrev.com/685b3cd46a695f860617f84024bc3ac83e4d2d27/ui/snapshot/BUILD.gn
[modify] https://crrev.com/685b3cd46a695f860617f84024bc3ac83e4d2d27/ui/snapshot/screenshot_grabber.cc
[modify] https://crrev.com/685b3cd46a695f860617f84024bc3ac83e4d2d27/ui/snapshot/screenshot_grabber.h
[delete] https://crrev.com/e64540177d347e0b1d5c334decd29fc815f0fa84/ui/snapshot/screenshot_grabber_observer.h

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

commit 261ab6469d907d349ce8bac2f8e67b0b0c9499f7
Author: Elliot Glaysher <erg@chromium.org>
Date: Thu Feb 15 01:05:33 2018

Add mojo support for base::RefCountedMemory.

RefCountedMemory is an arbitrary wrapper around memory. It is used
extensively in code which passes encoded PNG files around, such as the
history system and the screenshotting code.

Bug:  706246 
Change-Id: I9788aaba9dcfe38bd05418c4cc3a9e2737a5985c
Reviewed-on: https://chromium-review.googlesource.com/917198
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Reviewed-by: Ken Rockot <rockot@chromium.org>
Commit-Queue: Elliot Glaysher <erg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#536914}
[modify] https://crrev.com/261ab6469d907d349ce8bac2f8e67b0b0c9499f7/mojo/public/cpp/base/BUILD.gn
[add] https://crrev.com/261ab6469d907d349ce8bac2f8e67b0b0c9499f7/mojo/public/cpp/base/ref_counted_memory.typemap
[add] https://crrev.com/261ab6469d907d349ce8bac2f8e67b0b0c9499f7/mojo/public/cpp/base/ref_counted_memory_mojom_traits.cc
[add] https://crrev.com/261ab6469d907d349ce8bac2f8e67b0b0c9499f7/mojo/public/cpp/base/ref_counted_memory_mojom_traits.h
[add] https://crrev.com/261ab6469d907d349ce8bac2f8e67b0b0c9499f7/mojo/public/cpp/base/ref_counted_memory_unittest.cc
[modify] https://crrev.com/261ab6469d907d349ce8bac2f8e67b0b0c9499f7/mojo/public/cpp/base/typemaps.gni
[modify] https://crrev.com/261ab6469d907d349ce8bac2f8e67b0b0c9499f7/mojo/public/mojom/base/BUILD.gn
[add] https://crrev.com/261ab6469d907d349ce8bac2f8e67b0b0c9499f7/mojo/public/mojom/base/ref_counted_memory.mojom

Status: I have a straw patch which has screenshots working end to end in mash, but only if I disabled the allow_copy_output_requests_ check in viz. (https://chromium-review.googlesource.com/c/chromium/src/+/924620) I was confused and thought that the window manager was a privileged process; from the point of view of viz, it is not.

My patch needs a partial redesign so that the window server is responsible for doing the actual screenshotting in response to calls made by the window manager.

This leads up to a problem: the //ui/snapshot/ code all assume aura::Windows and ui::Layers, and the window server does not have these. I am unsure what would have to be done to reimplement snapshot on top of pure viz primitives if I were to move all this to the window server.

The //ui/snapshot code works by adding CopyOutputRequests to Layers. Sounds like you're going to need  bug 812059  to be done so that the window server would be able to call into FrameSinkManager (via a new API) to grab the screenshot from the Surface instead.

Would the window server (in VIZ) be able to access viz::FrameSinkManagerImpl directly, or does it go through mojo for that? We may need to update the "permission" mechanism to upgrade the window server to a "privileged" status from the perspective of VIZ.

An alternative is to upgrade the permissions of the window manager to trusted instead of the window server, which is where the current screenshot operation happens. The window manager is otherwise treated as trusted since it has access to the entire window hierarchy.

So the patch I wrote and linked to in #24 should just work if  issue 812059  gets fixed so that if the window manager gets read permissions. If the idea is that the window server should be the one that gets the read permission, additional plumbing from the window manager to the window server will need to be added to that patch.

Is this moot now? Issue 557397 is tracking fixing screenshots in Mash (i.e. replace ash::ScreenshotDelegate with a mojo API and a few other misc. fixes). If that is completed, should screenshots in Mash/OopMash "just work"?

rcui volunteered to take screenshots. rcui, see comments above.

Note that we no longer have a separate window service vs. window manager process -- the "ash" process now does both. It has a complete view of the aura window hierarchy.

It doesn't seem this is done for single process mash since all these tests still fail. See bug 877172

# CopyOutputRequests not allowed. https://crbug.com/877172
-AuraWindowVideoCaptureDeviceBrowserTest.DeliversRefreshFramesUponRequest
-AuraWindowVideoCaptureDeviceBrowserTest.ErrorsOutWhenWindowIsDestroyed
-AuraWindowVideoCaptureDeviceBrowserTestP.CapturesContentChanges/0
-AuraWindowVideoCaptureDeviceBrowserTestP.CapturesContentChanges/1
-AuraWindowVideoCaptureDeviceBrowserTest.SuspendsAndResumes
-CaptureScreenshotTest.CaptureScreenshot
-CaptureScreenshotTest.CaptureScreenshotJpeg
-CaptureScreenshotTest.SetDefaultBackgroundColorOverride
-CaptureScreenshotTest.TransparentScreenshots
-CompositedScrollingBrowserTest.Scroll3DTransformedScroller

example failure:
[141959:141959:1105/162942.874558:FATAL:async_layer_tree_frame_sink.cc(345)] CopyOutputRequests not allowed
#0 0x7efd8ba9d46f base::debug::StackTrace::StackTrace()
#1 0x7efd8b9ce36b logging::LogMessage::~LogMessage()
#2 0x7efd7ed434a8 cc::mojo_embedder::AsyncLayerTreeFrameSink::OnMojoConnectionError()
#3 0x7efd7ed4691c _ZN4base8internal7InvokerINS0_9BindStateIMN2cc13mojo_embedder23AsyncLayerTreeFrameSinkEFvjRKNSt3__112basic_stringIcNS6_11char_traitsIcEENS6_9allocatorIcEEEEEJNS_7WeakPtrIS5_EEEEEFvjSE_EE7RunOnceEPNS0_13BindStateBaseEjSE_
#4 0x7efd8c9d3339 mojo::InterfaceEndpointClient::NotifyError()
#5 0x7efd8c9da3c7 mojo::internal::MultiplexRouter::ProcessNotifyErrorTask()
#6 0x7efd8c9d70bb mojo::internal::MultiplexRouter::ProcessTasks()
#7 0x7efd8c9d8c2e mojo::internal::MultiplexRouter::Accept()
#8 0x7efd8c9d1776 mojo::FilterChain::Accept()
#9 0x7efd8c9cc68f mojo::Connector::ReadSingleMessage()
#10 0x7efd8c9cd1d1 mojo::Connector::ReadAllAvailableMessages()
#11 0x7efd8c9cd079 mojo::Connector::OnHandleReadyInternal()
#12 0x7efd8c9cd8c7 mojo::SimpleWatcher::DiscardReadyState()
#13 0x7efd8b8dbc14 mojo::SimpleWatcher::OnHandleReady()
#14 0x7efd8b8dc121 _ZN4base8internal7InvokerINS0_9BindStateIMN4mojo13SimpleWatcherEFvijRKNS3_18HandleSignalsStateEEJNS_7WeakPtrIS4_EEijS5_EEEFvvEE7RunImplIRKS9_RKNSt3__15tupleIJSB_ijS5_EEEJLm0ELm1ELm2ELm3EEEEvOT_OT0_NSI_16integer_sequenceImJXspT1_EEEE
#15 0x7efd8b9b163a base::debug::TaskAnnotator::RunTask()
#16 0x7efd8b9dd4ef base::MessageLoop::RunTask()
#17 0x7efd8b9dd8e3 base::MessageLoop::DoWork()
#18 0x7efd8bac0c79 base::MessagePumpLibevent::Run()
#19 0x7efd8b9dd094 base::MessageLoop::Run()
#20 0x7efd8ba0eca9 base::RunLoop::Run()
#21 0x55599f50f0ca content::(anonymous namespace)::AuraWindowVideoCaptureDeviceBrowserTest::WaitForFrameWithColor()
#22 0x55599f502502 content::ContentCaptureDeviceBrowserTestBase::AllocateAndStartAndWaitForFirstFrame()
#23 0x55599f50f547 content::(anonymous namespace)::AuraWindowVideoCaptureDeviceBrowserTest_DeliversRefreshFramesUponRequest_Test::RunTestOnMainThread()
#24 0x55599f6d6dc7 content::BrowserTestBase::ProxyRunTestOnMainThreadLoop()
#25 0x55599f7526a9 content::ShellBrowserMainParts::PreMainMessageLoopRun()
#26 0x7efd892985ba content::BrowserMainLoop::PreMainMessageLoopRun()
#27 0x7efd897912f5 content::StartupTaskRunner::RunAllTasksNow()
#28 0x7efd892970e1 content::BrowserMainLoop::CreateStartupTasks()
#29 0x7efd8929ace0 content::BrowserMainRunnerImpl::Initialize()
#30 0x55599f732a4d ShellBrowserMain()
#31 0x55599f7267d0 content::ShellMainDelegate::RunProcess()
#32 0x7efd89d61936 content::ContentMainRunnerImpl::RunServiceManager()
#33 0x7efd89d61827 content::ContentMainRunnerImpl::Run()
#34 0x7efd7f5b2e56 service_manager::Main()
#35 0x7efd89d5fd24 content::ContentMain()
#36 0x55599f6d6996 content::BrowserTestBase::SetUp()
#37 0x55599f5986cd testing::Test::Run()
#38 0x55599f5992f0 testing::TestInfo::Run()
#39 0x55599f599807 testing::TestCase::Run()
#40 0x55599f5a56f7 testing::internal::UnitTestImpl::RunAllTests()
#41 0x55599f5a526d testing::UnitTest::Run()
#42 0x55599f712771 base::TestSuite::Run()
#43 0x55599f6cf20a content::ContentTestLauncherDelegate::RunTestSuite()


over to sky@ for triage

Evan, any chance you could investigate this further.

So it seems that screenshots do work, thus reverting the labels. However I did notice a couple other issues: the tests suggest that devtools screenshots don't work, and before I can trigger one, there's a crash in cursor code, which I'll look into.

Devtools screenshots do work in Mash (instructions here: https://www.abhishekshukla.com/chrome/capture-screenshot-in-chrome-without-any-tool-plugin-extension/ ) but the tests still fail with the above.

miu@, you fixed CaptureScreenshotTest* for viz. Any idea what needs to be done for them to pass with --enable-features=SingleProcessMash as well?

Instead of morphing this bug to track the test failures, let's use bug 877172