New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 877172 link

Starred by 1 user
Status: Available
Owner: ----
Cc:
█ fsam...@chromium.org
m...@chromium.org
mustash-bugs@google.com
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug

Blocking:
issue 874089



Sign in to add a comment

SingleProcessMash content_browsertests failure: "CopyOutputRequests not allowed"

Project Member Reported by xiy...@chromium.org, Aug 23 
In the following tests:

AuraWindowVideoCaptureDeviceBrowserTest.DeliversRefreshFramesUponRequest
AuraWindowVideoCaptureDeviceBrowserTest.ErrorsOutWhenWindowIsDestroyed
AuraWindowVideoCaptureDeviceBrowserTest.SuspendsAndResumes
AuraWindowVideoCaptureDeviceBrowserTestP.CapturesContentChanges/0
AuraWindowVideoCaptureDeviceBrowserTestP.CapturesContentChanges/1

Typical stack:
[135519:135519:0823/124228.636507:FATAL:async_layer_tree_frame_sink.cc(262)] CopyOutputRequests not allowed                                                 
#0 0x7f0a90c05f8d base::debug::StackTrace::StackTrace()     
#1 0x7f0a90914d6c base::debug::StackTrace::StackTrace()        
#2 0x7f0a9097eded logging::LogMessage::~LogMessage()             
#3 0x7f0a725a8e9f cc::mojo_embedder::AsyncLayerTreeFrameSink::OnMojoConnectionError()
#4 0x7f0a725b24e1 _ZN4base8internal13FunctorTraitsIMN2cc13mojo_embedder23AsyncLayerTreeFrameSinkEFvjRKNSt3__112basic_stringIcNS5_11char_traitsIcEENS5_9allocatorIcEEEEEvE6InvokeISF_
NS_7WeakPtrIS4_EEJjSD_EEEvT_OT0_DpOT1_                                                                                                                                             
#5 0x7f0a725b23d5 _ZN4base8internal12InvokeHelperILb1EvE8MakeItSoIMN2cc13mojo_embedder23AsyncLayerTreeFrameSinkEFvjRKNSt3__112basic_stringIcNS7_11char_traitsIcEENS7_9allocatorIcEEE
EENS_7WeakPtrIS6_EEJjSF_EEEvOT_OT0_DpOT1_                                                                                                                                          
....
#42 0x000001203001 content::(anonymous namespace)::AuraWindowVideoCaptureDeviceBrowserTest::WaitForFrameWithColor()
#43 0x000001201dca content::(anonymous namespace)::AuraWindowVideoCaptureDeviceBrowserTest::WaitForFirstFrame()
#44 0x0000011e5743 content::ContentCaptureDeviceBrowserTestBase::AllocateAndStartAndWaitForFirstFrame()

Comment 1 by sky@chromium.org, Nov 5

Labels: Pri-2

Comment 2 by sky@chromium.org, Nov 5

Status: Available (was: Untriaged)

Comment 3 by est...@chromium.org, Nov 5 

there's some seemingly related discussion on  bug 706246

Comment 4 by est...@chromium.org, Nov 11

Owner: m...@chromium.org
Status: Assigned (was: Available)
miu@, you fixed CaptureScreenshotTest* for viz. Any idea what needs to be done for them to pass with --enable-features=SingleProcessMash as well?

Comment 5 by sky@chromium.org, Nov 13

Cc: fsam...@chromium.org m...@chromium.org
Labels: -Proj-Mash-SingleProcess Proj-Mash-MultiProcess
Owner: sky@chromium.org
This test triggers a scenario we don't support for single-process-mash, so I'm retargetting to multi-process. In particular it's doing a copy request on an aura::Window backed by mus. In single-process-mash we always issue copy requests on LOCAL windows. So, I'm retargetting to multi-process.

That said, I think the issue is we need to allow copy requests in windows created by the browser. Specifically I believe we need to make ServerWindow::AttachCompositorFrameSink() turn on allowing copy requests in CompositorFrameSinkSupport if the browser is at the other side.

I've sent out email to Fady/Yuri to make sure I have that right.

Comment 6 by sky@chromium.org, Nov 13

Labels: -Pri-2 Pri-3
Owner: ----
Status: Available (was: Assigned)
In talking with Fady it seems the right thing is to introduce an API to VizHost that enables ash to allow copyrequests for the browser. As this is only an issue for out-of-process-mash, I'm going to lower the priority
►

Sign in to add a comment