The bug description seems misleading; the bug IIUC is that the Content
Layer's GpuProcessTransportFactory assumes that it is the only
ui::ContextFactory, even though embedders are permitted to supply their own.

Thanks! I'll take a look right away.

Any updates here?  We'd like to have this addressed by Wednesday on trunk.

https://codereview.chromium.org/1808313002

So as enne@ found out in trying to fix this, overriding ContextFactory but at the same time still using GpuProcessTransportFactory accidentally (which also implements ContextFactory) is a bit weird in terms of defined behavior.

Was there any reason to stub out the ContextFactory other than to override CreateOutputSurface()? It's a bit surprising that this would happen, because you should never be showing a root window. There are probably multiple ways to avoid this but not calling OnAcceleratedWidgetAvailable() should help (see StubWindow).

On a separate note you probably also don't want to use DelegatedFrameHost and GpuProcessTransportFactory. You probably don't even want to use RenderWidgetHostViewAura, since it will probably soon cause issues with IME.

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

commit c9295554c6764463c506aca4b81c0ff95a851f86
Author: enne <enne@chromium.org>
Date: Thu Mar 24 17:58:02 2016

Register surface namespace in BlimpUiContextFactory

The BlimpUiContextFactory handles creating surface id allocators, so
also needs to register them as being valid surfaces with the surface
manager like GpuProcessTransportFactory does.

In order to do this, the surface manager and surface id allocator
logic from content/browser/compositor/surface_utils is hoisted up
into content/public/browser so that BlimpUiContextFactory can get
at the global SurfaceManager.

This is a band-aid fix, as it's possible for existing code to create
a surface using the GpuProcessTransportFactory::GetContextFactory
(which is the GpuProcessTransportFactory itself) instead of the
ui::aura::Env::GetInstance()->GetContextFactory() which is overridden
by Blimp and is the BlimpUiContextmanager.  This needs to be cleaned
up separately.

BUG= 595497 
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_site_isolation

Review URL: https://codereview.chromium.org/1808313002

Cr-Commit-Position: refs/heads/master@{#383096}

[modify] https://crrev.com/c9295554c6764463c506aca4b81c0ff95a851f86/blimp/engine/DEPS
[modify] https://crrev.com/c9295554c6764463c506aca4b81c0ff95a851f86/blimp/engine/app/ui/blimp_ui_context_factory.cc

About blimp, overriding ContextFactory.CreateOutputSurface is what we want.

In addition to not calling OnAcceleratedWidgetAvailable(), is it possible not to create a browser side Compositor? It seems lots of places assume the existence of such compositor. 

Could you suggest a way to avoid using RenderWidgetHostViewAura?  

#2 0x7f19f2f47e2c cc::SurfaceManager::RegisterSurfaceNamespaceHierarchy()
#3 0x7f19ee95e95c content::DelegatedFrameHost::SetCompositor()
#4 0x7f19ee5795e4 content::RenderWidgetHostViewAura::AddedToRootWindow()
#5 0x7f19ee57e63a content::RenderWidgetHostViewAura::WindowObserver::OnWindowAddedToRootWindow()
#6 0x7f19f1e31133 aura::Window::NotifyAddedToRootWindow()
#7 0x7f19f1e309e5 aura::Window::AddChild()
#8 0x7f19ee56f9c7 content::RenderWidgetHostViewAura::InitAsChild()
#9 0x7f19ee83946b content::WebContentsViewAura::CreateViewForWidget()
#10 0x7f19ee816f52 content::WebContentsImpl::CreateRenderWidgetHostViewForRenderManager()
#11 0x7f19ee8170f0 content::WebContentsImpl::CreateRenderViewForRenderManager()
#12 0x7f19ee07f307 content::RenderFrameHostManager::InitRenderView()
#13 0x7f19ee07dba9 content::RenderFrameHostManager::Navigate()
#14 0x7f19ee051085 content::NavigatorImpl::NavigateToEntry()
#15 0x7f19ee05212b content::NavigatorImpl::NavigateToPendingEntry()
#16 0x7f19ee02e75a content::NavigationControllerImpl::NavigateToPendingEntryInternal()
#17 0x7f19ee026f2c content::NavigationControllerImpl::NavigateToPendingEntry()
#18 0x7f19ee0274b9 content::NavigationControllerImpl::LoadEntry()
#19 0x7f19ee029541 content::NavigationControllerImpl::LoadURLWithParams()

Re #7: RWHV handles things related to the native view/window and has some other input-related things that are routed through it. So it depends a bit on what you'll end up wanting to support and how. But most likely you'll want to have your own RWHV implementation without any output.

Now that's a bit tricky if you compile with USE_AURA and what not since there might be places in the code where we statically cast the RWHV to a RWHVAura.

Ideally you'd be able to compile your engine without USE_AURA, since it's a windowing api and you don't have windows plus it might take you down a codepath accidentally that's desktop specific and does the wrong thing. But doing this might not be trivial. We should see if there is some overlap with the 'headless' effort.

Hmm content shell can now run headless for layout tests.
See https://codereview.chromium.org/71243002/diff/130001/content/browser/renderer_host/render_widget_host_view_aura.cc for example.

You can try making it run so that RWHVAura never attaches to the root window.
Then you can probably further stub out your WindowTreeHost so that it doesn't need ui::Compositor.

Blimp crash is fixed. I created a separate bug (597804, fixed) for it. This bug no longer blocks 597736.

Created crbug/597818 per sievers@ comment #7.