summaryrefslogtreecommitdiffstats
path: root/chrome/common
diff options
context:
space:
mode:
authorjam@chromium.org <jam@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2009-09-28 22:32:21 +0000
committerjam@chromium.org <jam@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2009-09-28 22:32:21 +0000
commit12636df0dcf36c769c8a5940d6a0c0b6b6a6647c (patch)
tree5ff7eccca7457afe24c47a277286c834108e825c /chrome/common
parentca3f22c070a6b61a3ec40ace07244890bbdd6ebe (diff)
downloadchromium_src-12636df0dcf36c769c8a5940d6a0c0b6b6a6647c.zip
chromium_src-12636df0dcf36c769c8a5940d6a0c0b6b6a6647c.tar.gz
chromium_src-12636df0dcf36c769c8a5940d6a0c0b6b6a6647c.tar.bz2
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
Diffstat (limited to 'chrome/common')
-rw-r--r--chrome/common/modal_dialog_event.h20
-rw-r--r--chrome/common/render_messages.h24
-rw-r--r--chrome/common/render_messages_internal.h11
3 files changed, 4 insertions, 51 deletions
diff --git a/chrome/common/modal_dialog_event.h b/chrome/common/modal_dialog_event.h
deleted file mode 100644
index 2a14c87..0000000
--- a/chrome/common/modal_dialog_event.h
+++ /dev/null
@@ -1,20 +0,0 @@
-// Copyright (c) 2006-2008 The Chromium Authors. All rights reserved.
-// Use of this source code is governed by a BSD-style license that can be
-// found in the LICENSE file.
-
-#ifndef CHROME_COMMON_MODAL_DIALOG_EVENT_H_
-#define CHROME_COMMON_MODAL_DIALOG_EVENT_H_
-
-// This structure is passed around where we need a modal dialog event, which
-// is currently not plumbed on Mac & Linux.
-//
-// TODO(port) Fix this. This structure should probably go away and we should
-// do the modal dialog event in some portable way. If you remove this, be
-// sure to also remove the ParamTraits for it in resource_messages.h
-struct ModalDialogEvent {
-#if defined(OS_WIN)
- HANDLE event;
-#endif
-};
-
-#endif // CHROME_COMMON_MODAL_DIALOG_EVENT_H_
diff --git a/chrome/common/render_messages.h b/chrome/common/render_messages.h
index 8bc8405..99a4a68 100644
--- a/chrome/common/render_messages.h
+++ b/chrome/common/render_messages.h
@@ -22,7 +22,6 @@
#include "chrome/common/extensions/update_manifest.h"
#include "chrome/common/extensions/url_pattern.h"
#include "chrome/common/filter_policy.h"
-#include "chrome/common/modal_dialog_event.h"
#include "chrome/common/navigation_gesture.h"
#include "chrome/common/page_transition_types.h"
#include "chrome/common/renderer_preferences.h"
@@ -1726,29 +1725,6 @@ struct ParamTraits<WebDropData> {
}
};
-template<>
-struct ParamTraits<ModalDialogEvent> {
- typedef ModalDialogEvent param_type;
-#if defined(OS_WIN)
- static void Write(Message* m, const param_type& p) {
- WriteParam(m, p.event);
- }
- static bool Read(const Message* m, void** iter, param_type* p) {
- return ReadParam(m, iter, &p->event);
- }
-#else
- static void Write(Message* m, const param_type& p) {
- }
- static bool Read(const Message* m, void** iter, param_type* p) {
- return true;
- }
-#endif
-
- static void Log(const param_type& p, std::wstring* l) {
- l->append(L"<ModalDialogEvent>");
- }
-};
-
// Traits for AudioManager::Format.
template <>
struct ParamTraits<AudioManager::Format> {
diff --git a/chrome/common/render_messages_internal.h b/chrome/common/render_messages_internal.h
index ac124b5..28dc35b 100644
--- a/chrome/common/render_messages_internal.h
+++ b/chrome/common/render_messages_internal.h
@@ -69,9 +69,8 @@ IPC_BEGIN_MESSAGES(View)
// Tells the renderer to create a new view.
// This message is slightly different, the view it takes is the view to
// create, the message itself is sent as a non-view control message.
- IPC_MESSAGE_CONTROL5(ViewMsg_New,
+ IPC_MESSAGE_CONTROL4(ViewMsg_New,
gfx::NativeViewId, /* parent window */
- ModalDialogEvent, /* model dialog box event */
RendererPreferences,
WebPreferences,
int32 /* view id */)
@@ -769,13 +768,11 @@ IPC_END_MESSAGES(View)
IPC_BEGIN_MESSAGES(ViewHost)
// Sent by the renderer when it is creating a new window. The browser creates
// a tab for it and responds with a ViewMsg_CreatingNew_ACK. If route_id is
- // MSG_ROUTING_NONE, the view couldn't be created. modal_dialog_event is set
- // by the browser when a modal dialog is shown.
- IPC_SYNC_MESSAGE_CONTROL2_2(ViewHostMsg_CreateWindow,
+ // MSG_ROUTING_NONE, the view couldn't be created.
+ IPC_SYNC_MESSAGE_CONTROL2_1(ViewHostMsg_CreateWindow,
int /* opener_id */,
bool /* user_gesture */,
- int /* route_id */,
- ModalDialogEvent /* modal_dialog_event */)
+ int /* route_id */)
// Similar to ViewHostMsg_CreateWindow, except used for sub-widgets, like
// <select> dropdowns. This message is sent to the TabContents that