| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This splits the ipc code from the common project. The 'common' project pulls in
all of webkit, the v8 bindings, skia, googleurl, and a number of other projects
which makes it very difficult to deal with especially for external projects
wanting just to use some of Chromium's infrastructure. This puts the ipc code
into its top-level ipc/ directory with a dependency only on base. The common
project depends on the new ipc/ipc.gyp:ipc target so that all projects currently
pulling common in to get the IPC code still have it available. This mostly
follows agl's pre-gyp attempt to do this which was r13062.
Known issues:
- Currently a number of projects depend on chrome/chrome.gyp:common in order to
use the IPC infrastructure. Rather than fixing all of these dependencies I have
made common depend on ipc/ipc.gyp:ipc and added "ipc" to the include_rules
section of DEPS so that checkdeps.py doesn't complain. Over time projects that
need IPC should depend on the IPC project themselves and dependencies on common
removed, although I don't think many projects that need IPC will be able to get
away without common currently.
- ipc/ipc_message_macros.h still has #include "chrome/common/..." inside of a
ipc/ should not refer to files in chrome/... now. I'm not sure how to resolve
this since it's really an IDE bug
- the named pipe name (windows+linux) and the logging event name (all) + env
variable (posix) refer explicitly to 'Chrome' which somewhat hurts the illusion
of ipc/ being an independent library. I think this should be examined in a
subsequent, much smaller patch.
- I've eliminated the IPC.SendMsgCount counter since it was implemented in a way
to create a dependency from ipc/ to chrome/common/chrome_counters. This is the
same approach that r13062 took.
http://codereview.chromium.org/155905
(Patch from James Robinson)
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21342 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This should make it non-flaky, so I un-disabled the test. I also added necessary plumbing so we can
wait for AppModalDialog to appear and close it.
TEST=Covered by browser_tests.
http://crbug.com/16062
Review URL: http://codereview.chromium.org/149460
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20400 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
a bug 10699.
Not sure what is causing the crasher.
Hopefully after this clean-up we'll get a different stack-trace that might help.
BUG=10699
TEST=Make sure alert/confirm boxes work properly. make sure a background tab that shows a (delayed) alert box works. Same with a background browser.
Review URL: http://codereview.chromium.org/113932
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17078 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
plugins display alerts via the NPN_Evaluate API. The browser signals an event handle to ensure that the plugin starts peeking for messages while waiting for the NPN_Evaluate call to return. When the dialog is dismissed by the user, windows does send some messages to the plugin window underneath, like activation messages, etc. These don't get dispatched as the event is reset when the dialog is dismissed, i.e. much before the window is actually
destroyed.
The fix is to reset the event handle after the window is actually destroyed. To achieve this I added an OnClose virtual function to the DialogDelegate interface, which is overridden by the JavascriptMessageBoxDialog class which eventually ensures that the event is reset.
This fixes http://code.google.com/p/chromium/issues/detail?id=10799
I updated the AlertInWindowMessage npapi test to display two alerts instead of one.
Bug=10799
Review URL: http://codereview.chromium.org/113464
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16172 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
| |
Review URL: http://codereview.chromium.org/99177
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15194 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is the same except in tab_strip_model_unittest I fixed a leak by making a
WebContents on the stack, I added a factory to the SiteInstance unittest to
prevent another leak, and I re-added a NULL set to the external_tab_container.
Fix the ownership model of TabContents and NavigationController. Previously the
NavigationController owned the TabContents, and there were extra steps required
at creation and destruction to clean everything up properly.
NavigationController is now a member of TabContents, and there is no setup or
tear down necessary other than the constructor and destructor. I could remove
the tab contents creation in the NavigationController, as well as all the
weird destruction code in WebContents which got moved to the destructor.
I made the controller getter return a reference since the ownership is clear
and there is no possibility of NULL. This required changing a lot of tiles, but
many of them were simplified since they no longer have to NULL check.
Previous review URL: http://codereview.chromium.org/69043
Review URL: http://codereview.chromium.org/67294
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14053 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14006 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NavigationController owned the TabContents, and there were extra steps required
at creation and destruction to clean everything up properly.
NavigationController is now a member of TabContents, and there is no setup or
tear down necessary other than the constructor and destructor. I could remove
the tab contents creation in the NavigationController, as well as all the
weird destruction code in WebContents which got moved to the destructor.
I made the controller getter return a reference since the ownership is clear
and there is no possibility of NULL. This required changing a lot of tiles, but
many of them were simplified since they no longer have to NULL check.
Review URL: http://codereview.chromium.org/69043
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14005 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
JavascriptMessageBoxHandler (handles alert, confirm, prompt, and onbeforeunload) was a views class. This change converts it into an MVC so we can port to linux/mac.
AppModalDialog is the model+controller, JavascriptMessageBoxDialog is the windows specific view.
The onbeforeunload dialog (JavascriptBeforeUnloadHandler) was a subclass of JavascriptMessageBoxHandler that had a different title and button text. I merged this class into JavascriptMessageBoxHandler by passing a bool to handle the custom button text.
Review URL: http://codereview.chromium.org/63033
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13276 0039d316-1c4b-4281-b951-d872f2087c98
|
