summaryrefslogtreecommitdiffstats
path: root/chrome/renderer/render_thread.cc
Commit message (Collapse)AuthorAgeFilesLines
...
* Reference and create a RenderView when needed.jrg@chromium.org2009-02-061-3/+10
| | | | | | | | | This initiates the landslide of linker hell in Chromium.app, bringing in webkit, v8, and the kitchen sink. Review URL: http://codereview.chromium.org/21123 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9335 0039d316-1c4b-4281-b951-d872f2087c98
* Prevent renderer from crashing on startup.jrg@chromium.org2009-02-061-6/+2
| | | | | | | | With pinkerton and jeremy. Review URL: http://codereview.chromium.org/20120 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9300 0039d316-1c4b-4281-b951-d872f2087c98
* Finish taking out render_messages.h includes from headers.jam@chromium.org2009-02-051-0/+1
| | | | | | Review URL: http://codereview.chromium.org/20072 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9209 0039d316-1c4b-4281-b951-d872f2087c98
* Unit test addition, cleanup for render_process/thread.jrg@chromium.org2009-01-281-6/+0
| | | | | | Review URL: http://codereview.chromium.org/19606 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8782 0039d316-1c4b-4281-b951-d872f2087c98
* MAC: build fixagl@chromium.org2009-01-271-0/+4
| | | | | | | Review URL: http://codereview.chromium.org/19040 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8759 0039d316-1c4b-4281-b951-d872f2087c98
* POSIX: gfx::NativeViewId and CrossProcessEventagl@chromium.org2009-01-271-7/+9
| | | | | | | | | | | | | | | | | | | Create a couple new typedefs for porting work. Firstly, gfx::NativeViewId is a handle to a platform specific widget in the renderer process. For Windows, this is just a HWND as before. However, in other platforms the ids used in the renderer process will be something else. CrossProcessEvent is the type of a HANDLE to a Windows event object which is used across processes. Since we aren't going to support these sorts of events on non-Windows platforms, this will have to go away at some point. For now, however, this lets us build code without too many ifdefs all over the place. Review URL: http://codereview.chromium.org/18768 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8756 0039d316-1c4b-4281-b951-d872f2087c98
* render_* work.jrg@chromium.org2009-01-271-1/+54
| | | | | | Review URL: http://codereview.chromium.org/18650 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8732 0039d316-1c4b-4281-b951-d872f2087c98
* Fixing a crash when plugin messages are sent to dialogs.zork@google.com2009-01-161-0/+3
| | | | | | Review URL: http://codereview.chromium.org/18130 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8189 0039d316-1c4b-4281-b951-d872f2087c98
* WaitableEvent is the replacement for Windows events. Previously in the code, ↵agl@chromium.org2009-01-151-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | a HANDLE from CreateEvent was used for signaling, both within a process and across processes. WaitableEvent is the cross platform replacement for this. To convert: * HANDLE -> base::WaitableEvent* * ScopedHandle -> scoped_ptr<base::WaitableEvent> * CreateEvent -> new base::WaitableEvent * SetEvent -> base::WaitableEvent::Signal * ResetEvent -> base::WaitableEvent::Reset * ObjectWatcher -> base::WaitableEventWatcher * WaitForMultipleObjects -> static base::WaitableEvent::WaitMany ObjectWatcher remains for Windows specific code. WaitableEventWatcher has an identical interface save, * It uses WaitableEvents, not HANDLEs * It returns void from StartWatching and StopWatcher, rather than errors. System internal errors are fatal to the address space IMPORTANT: There are semantic differences between the different platforms. WaitableEvents on Windows are implemented on top of events. Windows events work across process and this is used mostly for modal dialog support. Windows events can be duplicated with DuplicateHandle. On other platforms, WaitableEvent works only within a single process. In the future we shall have to replace the current uses of cross-process events with IPCs. BEWARE: HANDLE, on Windows, is a void *. Since any pointer type coerces to void *, you can pass a WaitableEvent * where a HANDLE is expected without any build-time errors. Review URL: http://codereview.chromium.org/16554 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8126 0039d316-1c4b-4281-b951-d872f2087c98
* This is a rename of the term 'Greasemonkey' to 'user script' in Chromium.aa@chromium.org2009-01-091-9/+9
| | | | | | | | | | | I'm doing this to avoid confusion with the Firefox version of Greasemonkey and also because 'user script' is really the correct generic term. At the same time, I also moved user_script_master* into extensions/ because I want these two pieces to get closer and closer such that standalone user scripts are just a very small extension. Also extensions will be relying on most of the user script code. Review URL: http://codereview.chromium.org/17281 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7827 0039d316-1c4b-4281-b951-d872f2087c98
* Move plugins to FilePaths, some cleanupavi@google.com2009-01-061-2/+2
| | | | | | Review URL: http://codereview.chromium.org/16456 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7588 0039d316-1c4b-4281-b951-d872f2087c98
* Refactor the render widget unittest so it can be reused to create a render viewbrettw@chromium.org2009-01-051-3/+3
| | | | | | | | | | | | | | | | | unit test. Change the mock render thread to save all IPC messages it is asked to send so that tests can verify that the correct ones were sent. There are some new functions that support this checking. Plumb the form state change notification through the render view so that we will correctly update the form state to the browser. Write two RenderView unit tests. One arbitrarily tests OnLoadAlternateHTMLText which I used as a testcase for my testing framework. The other tests the above form state change notification. I had to expose the timeout of this message through the RenderView API so that the test can change it. Review URL: http://codereview.chromium.org/16482 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7549 0039d316-1c4b-4281-b951-d872f2087c98
* Make the global render thread object a regular global object rather than abrettw@google.com2008-12-181-14/+6
| | | | | | | | | | | special TLS value. This is slightly faster for this commonly-used function, and we don't ever have more than one (it's like this because we were originally planning on having more than one RenderThread). BUG=5635 Review URL: http://codereview.chromium.org/15052 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7272 0039d316-1c4b-4281-b951-d872f2087c98
* Add Terminate() to the Process object, have RenderProcessHost use this to ↵brettw@google.com2008-11-141-3/+4
| | | | | | | | | | avoid some more Windows specific code. Move Process and SharedMemory into the base namespace (most changes). Review URL: http://codereview.chromium.org/10895 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@5446 0039d316-1c4b-4281-b951-d872f2087c98
* Remove throttling code from the Browser process and implement throttling in ↵erg@google.com2008-10-171-3/+2
| | | | | | | | | | | | | the Renderer. The previous way of doing throttling was just calling CloseContents() on a window to reject it. But since the Browser is notified about a window opening asynchronously, by the time the CloseContents() sends a message back to the Renderer, a bunch more windows have been opened, leading to memory exhaustion. Instead, make all RenderViews created from a parent RenderView share a counter and start refusing to create RenderViews if too many RV have been created. Every RenderView (except for the first one) is assumed to be an unrequested popup, until notified by the Browser process by either a ViewMsg_DisassociateFromPopupCount message (this RenderView is a new top level page) or a ViewMsg_DisassociatePopup message (this RenderView is a requested popup and therefore shouldn't count against the count.) BUG=3382, 2632 Review URL: http://codereview.chromium.org/7388 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@3568 0039d316-1c4b-4281-b951-d872f2087c98
* Adds a bit of Greasemonkey support hidden behind the --enable-greasemonkey ↵aa@google.com2008-10-161-2/+13
| | | | | | | | | | | | | flag. Implementation follows the pattern of the visited links system. Things still to be done: - stop using a hardcoded script directory - watch script directory and update shared memory when necessary - move file io to background thread - support for @include patterns -- now, all scripts are applied to all pages Review URL: http://codereview.chromium.org/7254 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@3496 0039d316-1c4b-4281-b951-d872f2087c98
* Adding sync plugin messages, and plugin broadcasts to the renderer processeszork@google.com2008-09-151-0/+13
| | | | | | Review URL: http://codereview.chromium.org/2411 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2246 0039d316-1c4b-4281-b951-d872f2087c98
* Move a bunch of code from the old to new TLS interface.deanm@chromium.org2008-09-101-4/+10
| | | | | | Review URL: http://codereview.chromium.org/1660 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1982 0039d316-1c4b-4281-b951-d872f2087c98
* Chrome changes corresponding to my message_loop_type CL.darin@google.com2008-08-261-1/+7
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1363 0039d316-1c4b-4281-b951-d872f2087c98
* Use a more compact license header in source files.license.bot2008-08-241-28/+4
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1287 0039d316-1c4b-4281-b951-d872f2087c98
* TrackedObjects assumes you can use a "TLS slot" of -1 to indicate ↵evanm@google.com2008-08-201-4/+4
| | | | | | uninitialized. This isn't true for the pthread_key_t type, which is unsigned on Linux and reportedly a struct on Macs. This change modifies the Slot type to be a struct containing an "initialized" flag. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1122 0039d316-1c4b-4281-b951-d872f2087c98
* Revert. Failing unit tests.evanm@google.com2008-08-201-4/+4
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1118 0039d316-1c4b-4281-b951-d872f2087c98
* TrackedObjects assumes you can use a "TLS slot" of -1 to indicate ↵evanm@google.com2008-08-201-4/+4
| | | | | | uninitialized. This isn't true for the pthread_key_t type, which is unsigned on Linux and reportedly a struct on Macs. This change modifies the Slot type to be a struct containing an "initialized" flag. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1113 0039d316-1c4b-4281-b951-d872f2087c98
* Step 1 at making Gears run in the renderer process (enabled by switchmpcomplete@google.com2008-08-151-0/+5
| | | | | | | | | "--gears-in-renderer"). Requires some changes to gears to work. Most things work if you disable the sandbox. One major hole is that update tasks don't report status to the appropriate renderer. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@954 0039d316-1c4b-4281-b951-d872f2087c98
* Introduce MessagePump to represent the native message pump used to drive adarin@google.com2008-08-151-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MessageLoop. A MessageLoop now has a MessagePump. This will make it possible to port the MessagePump interface to other platforms as well as to use an IO completion port for our worker threads on Windows. Currently, there is only MessagePumpWin, which attempts to preserve the pre-existing behavior of the MessageLoop. API changes to MessageLoop: 1. MessageLoop::Quit means return from Run when the MessageLoop would otherwise wait for more work. 2. MessageLoop::Quit can no longer be called outside the context of an active Run call. So, things like this: MessageLoop::current()->Quit(); MessageLoop::current()->Run(); are now: MessageLoop::current()->RunAllPending(); 3. MessageLoop::Quit can no longer be called from other threads. This means that PostTask(..., new MessageLoop::QuitTask()) must be used explicitly to Quit across thread boundaries. 4. No protection is made to deal with nested MessageLoops involving watched objects or APCs. In fact, an assertion is added to flag such cases. This is a temporary measure until object watching and APC facilities are removed in favor of a MessagePump designed around an IO completion port. As part of this CL, I also changed the automation system to use an IPC::ChannelProxy instead of an IPC::Channel. This moves the automation IPC onto Chrome's IO thread where it belongs. I also fixed some abuses of RefCounted in the AutomationProvider class. It was deleting itself in some cases! This led to having to fix the ownership model for AutomationProvider, which explains the changes to AutomationProviderList and so on. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@928 0039d316-1c4b-4281-b951-d872f2087c98
* Manually refcount ReceivedSyncMsgQueue so that we force it to be destructed onjabdelmalek@google.com2008-08-121-0/+4
| | | | | | | | the listener thread. I've fixed the renderer crashes which were happening because SyncChannel was going away before the listener thread. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@762 0039d316-1c4b-4281-b951-d872f2087c98
* Enabling sync_channel in the browser to allow accessibility code making ↵jcampan@google.com2008-08-121-1/+2
| | | | | | | | | blocking calls. This replaces my previous CL that was somehow duplicating some of these functionalities. BUG=None TEST=Run the unit tests. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@691 0039d316-1c4b-4281-b951-d872f2087c98
* Add chrome to the repository.initial.commit2008-07-261-0/+220
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-03-28 23:06:55 +0000