Can you post stacks of the threads that are deadlocked.

Do you happen to have the #top-chrome-md flag set to "Material" or "Material Hybrid" in chrome://flags?

I can't reproduce on the latest Chrome OS canary (51.0.2692.0) (regardless of the state of #top-chrome-md) so it seems this is probably Windows-specific.

+varkha@ since he was working on bubble code recently.

Evan recently changed the base class for LocationBarBubbleDelegateView (not sure if related).

We are still affected. Try to open the identity popup and press the tab add button to close it. Will result in deadlock!

--disable-direct-composition resolves the problem, the offending commit was the one enabling direct composition by default.

Please prioritize. It may just need a new entry in gpu bugs AFAICS. The problematic driver is Intel integrated GPU's if I am right.

ananta@ any clue to what is happening? Sorry for nagging but this is a big deal IMHO.

I can't repro on win7. mboc, can you attach stacks of the threads that are deadlocked?

sky@ GPU process waits for work normally, main thread of UI waits:

>	base.dll!base::WaitableEvent::WaitMany(base::WaitableEvent * * events, unsigned int count) Line 92	C++
 	ipc.dll!IPC::SyncChannel::WaitForReply(IPC::SyncChannel::SyncContext * context, base::WaitableEvent * pump_messages_event) Line 553	C++
 	ipc.dll!IPC::SyncChannel::SendWithTimeout(IPC::Message * message, int timeout_ms) Line 534	C++
 	ipc.dll!IPC::SyncChannel::Send(IPC::Message * message) Line 489	C++
 	gpu.dll!gpu::GpuChannelHost::Send(IPC::Message * msg) Line 121	C++
 	gpu.dll!gpu::CommandBufferProxyImpl::Send(IPC::Message * msg) Line 714	C++
 	gpu.dll!gpu::CommandBufferProxyImpl::WaitForGetOffsetInRange(int start, int end) Line 364	C++
 	gpu.dll!gpu::CommandBufferHelper::WaitForGetOffsetInRange(int start, int end) Line 169	C++
 	gpu.dll!gpu::CommandBufferHelper::Finish() Line 222	C++
 	gles2_implementation.dll!gpu::gles2::GLES2Implementation::FinishHelper() Line 1421	C++
 	gles2_implementation.dll!gpu::gles2::GLES2Implementation::Finish() Line 1397	C++
 	cc.dll!cc::ResourceProvider::~ResourceProvider() Line 499	C++
 	[External Code]	
 	cc.dll!cc::LayerTreeHostImpl::~LayerTreeHostImpl() Line 305	C++
 	[External Code]	
 	cc.dll!cc::SingleThreadProxy::Stop() Line 368	C++
 	cc.dll!cc::LayerTreeHost::~LayerTreeHost() Line 360	C++
 	[External Code]	
 	compositor.dll!ui::Compositor::~Compositor() Line 241	C++
 	[External Code]	
 	aura.dll!aura::WindowTreeHost::DestroyCompositor() Line 225	C++
 	views.dll!views::DesktopWindowTreeHostWin::HandleDestroying() Line 777	C++
 	views.dll!views::HWNDMessageHandler::OnDestroy() Line 1367	C++
 	views.dll!views::HWNDMessageHandler::_ProcessWindowMessage(HWND__ * hWnd, unsigned int uMsg, unsigned int wParam, long lParam, long & lResult, unsigned long dwMsgMapID) Line 381	C++
 	views.dll!views::HWNDMessageHandler::OnWndProc(unsigned int message, unsigned int w_param, long l_param) Line 899	C++
 	gfx.dll!gfx::WindowImpl::WndProc(HWND__ * hwnd, unsigned int message, unsigned int w_param, long l_param) Line 303	C++
 	gfx.dll!base::win::WrappedWindowProc<&gfx::WindowImpl::WndProc>(HWND__ * hwnd, unsigned int message, unsigned int wparam, long lparam) Line 76	C++
 	[External Code]	
 	views.dll!views::HWNDMessageHandler::CloseNow() Line 440	C++
 	views.dll!base::internal::RunnableAdapter<void (__thiscall views::HWNDMessageHandler::*)(void)>::Run<views::HWNDMessageHandler *>(views::HWNDMessageHandler * && receiver_ptr) Line 187	C++
 	views.dll!base::internal::InvokeHelper<1,void>::MakeItSo<base::internal::RunnableAdapter<void (__thiscall views::HWNDMessageHandler::*)(void)> &,base::WeakPtr<views::HWNDMessageHandler> >(base::internal::RunnableAdapter<void (__thiscall views::HWNDMessageHandler::*)(void)> & runnable, base::WeakPtr<views::HWNDMessageHandler> weak_ptr) Line 326	C++
 	views.dll!base::internal::Invoker<base::IndexSequence<0>,base::internal::BindState<base::internal::RunnableAdapter<void (__thiscall views::HWNDMessageHandler::*)(void)>,void __cdecl(views::HWNDMessageHandler *),base::WeakPtr<views::HWNDMessageHandler> >,1,void __cdecl(void)>::Run(base::internal::BindStateBase * base) Line 363	C++
 	base.dll!base::Callback<void __cdecl(void),1>::Run() Line 397	C++
 	base.dll!base::debug::TaskAnnotator::RunTask(const char * queue_function, const base::PendingTask & pending_task) Line 53	C++
 	base.dll!base::MessageLoop::RunTask(const base::PendingTask & pending_task) Line 485	C++
 	base.dll!base::MessageLoop::DeferOrRunPendingTask(const base::PendingTask & pending_task) Line 496	C++
 	base.dll!base::MessageLoop::DoWork() Line 610	C++
 	base.dll!base::MessagePumpForUI::DoRunLoop() Line 185	C++
 	base.dll!base::MessagePumpWin::RunWithDispatcher(base::MessagePump::Delegate * delegate, base::MessagePumpDispatcher * dispatcher) Line 62	C++
 	base.dll!base::MessagePumpWin::Run(base::MessagePump::Delegate * delegate) Line 67	C++
 	base.dll!base::MessageLoop::RunHandler() Line 449	C++
 	base.dll!base::RunLoop::Run() Line 52	C++

I'll just add I'm on Win10 v 1511 b 10586.420

Anyone?

Thanks for pinging as I missed the trace pasted in in comment #10. It looks like the UI is stuck waiting on IPC from gpu. I'm trimming the cc list to just the folks that hopefully know what is going on (and keeping myself).
+piman, danakj, jbauman : any ideas on why we might be wedged here?

Can we get a backtrace of the gpu process? Personally I can't guess at what it would be waiting for, maybe others can divine more.

We'd have to inspect what's going on in the GPU process. @#10: How hard would it be to dump a stack trace?

I think r418030 should fix this, in almost all cases. PeekMessage on a WS_DISABLED window seems to be trying to synchronously send touch messages to the parent window, causing this deadlock. Putting the window's message loop on a separate thread should prevent that.

I'm also looking into a more elegant fix where we have a transparent window in the browser process that intercepts touch events and handles them without letting them go to the GPU process.

Could you check and see if this is working for you in canary?

jbauman@ does this look fixed?

mboc@opera.com: can you please try canary and verify if this is resolved for you?

+mboc@opera.com

mboc@, please check if this is fixed for you

This seems to be mostly working, though I'd still like to have the complete fix I mentioned in comment 18 some day.