From 12636df0dcf36c769c8a5940d6a0c0b6b6a6647c Mon Sep 17 00:00:00 2001 From: "jam@chromium.org" Date: Mon, 28 Sep 2009 22:32:21 +0000 Subject: Fix deadlock when plugin puts an alert and right afterwards the browser process makes a win32 call that ends up waiting on the plugin. Since the plugin thread is blocked, the Windows message doesn't get dispatched and the browser ui thread deadlocks. The message from the renderer would make the plugin run a nested message loop but it doesn't get run on the browser ui thread since it's blocked. The fix is to set the event that runs nested message loop in the renderer process. BUG=23147 TEST=ui tests already cover nested message loops and plugins. This particular scenario is hard to write a test case for because it's a race condition involving the browser. Review URL: http://codereview.chromium.org/243018 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@27421 0039d316-1c4b-4281-b951-d872f2087c98 --- chrome/browser/views/dom_view.cc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'chrome/browser/views/dom_view.cc') diff --git a/chrome/browser/views/dom_view.cc b/chrome/browser/views/dom_view.cc index c8cebf7..a1bf0dc 100644 --- a/chrome/browser/views/dom_view.cc +++ b/chrome/browser/views/dom_view.cc @@ -21,8 +21,8 @@ bool DOMView::Init(Profile* profile, SiteInstance* instance) { return true; initialized_ = true; - tab_contents_.reset(new TabContents(profile, instance, - MSG_ROUTING_NONE, NULL, NULL)); + tab_contents_.reset( + new TabContents(profile, instance, MSG_ROUTING_NONE, NULL)); views::NativeViewHost::Attach(tab_contents_->GetNativeView()); return true; } -- cgit v1.1