summaryrefslogtreecommitdiffstats
path: root/chrome/common/plugin_messages_internal.h
Commit message (Collapse)AuthorAgeFilesLines
* Another attempt at landing this patch.ananta@chromium.org2009-08-041-11/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | The reliability tests regressions caused by this patch have been addressed by the upstream bug fix https://bugs.webkit.org/show_bug.cgi?id=27769 The IPCs for carrying data requested by plugins have been changed from synchronous IPCs to asynchronous IPCs. This fixes bug http://code.google.com/p/chromium/issues/detail?id=14323, where the Flash plugin would not render content on the page if these IPCs were processed while the plugin waited for sync calls like NPN_Evaluate to return. This CL also fixes the following bugs, which were crashes in reliability test runs when this patch was landed last time. http://code.google.com/p/chromium/issues/detail?id=18058 http://code.google.com/p/chromium/issues/detail?id=18059 The crash happens because of NPP_Write calls issued to the plugin while it is waiting for an NPN_Invoke call to return in the context of NPP_NewStream. Inspecting the safari plugin implementation revealed that they defer the resource load before calling the plugin and restore it on return. We emulate this behavior via an IPC sent from the plugin which serves as an acknowledgement. Test=covered by UI tests. Bug=14323,18058,18059 Review URL: http://codereview.chromium.org/159746 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22369 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting 22041 as it caused plugin crashes in reliability test runs.ananta@chromium.org2009-07-301-10/+11
| | | | | | | | | | Also reverting 22065/22046/22041 which are changes to knowncrashes.txt. TBR=huanr Review URL: http://codereview.chromium.org/160418 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22109 0039d316-1c4b-4281-b951-d872f2087c98
* Another attempt at landing this patch. ananta@chromium.org2009-07-301-11/+10
| | | | | | | | | | | | | | | | | | | | | | The reliability tests regressions caused by this patch have been addressed by the upstream bug fix https://bugs.webkit.org/show_bug.cgi?id=27769 The IPCs for carrying data requested by plugins have been changed from synchronous IPCs to asynchronous IPCs. This fixes bug http://code.google.com/p/chromium/issues/detail?id=14323, where the Flash plugin would not render content on the page if these IPCs were processed while the plugin waited for sync calls like NPN_Evaluate to return. Test=covered by UI tests. Bug=14323 Review URL: http://codereview.chromium.org/160338 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22041 0039d316-1c4b-4281-b951-d872f2087c98
* Revert r21548 and r21559 due to crash spike.huanr@chromium.org2009-07-251-10/+11
| | | | | | Review URL: http://codereview.chromium.org/159383 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21614 0039d316-1c4b-4281-b951-d872f2087c98
* The IPCs for carrying data requested by plugins have been changed from ↵ananta@chromium.org2009-07-241-11/+10
| | | | | | | | | | | | | | | | synchronous IPCs to asynchronous IPCs. This fixes bug http://code.google.com/p/chromium/issues/detail?id=14323, where the Flash plugin would not render content on the page if these IPCs were processed while the plugin waited for sync calls like NPN_Evaluate to return. Test=covered by UI tests. Bug=14323 Review URL: http://codereview.chromium.org/159296 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21548 0039d316-1c4b-4281-b951-d872f2087c98
* CPAPI (0.11) for gears drag drop.mpcomplete@chromium.org2009-07-231-1/+8
| | | | | | | | | | | | Provide a method that allows the gears plugin to ask the browser process to verify that its renderer has permission to access the drop files. Update the copyright notices. BUG=7995 Review URL: http://codereview.chromium.org/159074 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21437 0039d316-1c4b-4281-b951-d872f2087c98
* Split the IPC code into ipc/agl@chromium.org2009-07-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Wire up windowless plugins. Mostly Mac related, some crossamanda@chromium.org2009-07-111-2/+2
| | | | | | | | | | platform aspects. BUG=10809 TEST=none Review URL: http://codereview.chromium.org/113637 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20453 0039d316-1c4b-4281-b951-d872f2087c98
* linux: OOP windowed pluginsevan@chromium.org2009-07-071-1/+21
| | | | | | | | | | | | | | There are still a few issues, but that's a start. - only windowed plugins - we can't currently create the gtksocket in background tabs, because their gtkwidgets are not yet in the hierarchy, so they can't be realized (that's what gives the XID). - the plugin process talks to the browser process through the renderer process to create/destroy the gtksockets, because the plugin doesn't know which renderer it's talking to. We need a bit more plumbing to be able to have direct IPC. - some code is duplicated between chrome and test_shell. We should probably refactor it, but I'm not sure where the common part should live. Patch from Antoine Labour <piman@google.com>, with some touchups by me. Review URL: http://codereview.chromium.org/146078 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20041 0039d316-1c4b-4281-b951-d872f2087c98
* Revert "linux: OOP windowed plugins"evan@chromium.org2009-07-061-21/+1
| | | | | | This reverts r19983. Test failures on Mac and Windows. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19988 0039d316-1c4b-4281-b951-d872f2087c98
* linux: OOP windowed pluginsevan@chromium.org2009-07-061-1/+21
| | | | | | | | | | | | There are still a few issues, but that's a start. - only windowed plugins - we can't currently create the gtksocket in background tabs, because their gtkwidgets are not yet in the hierarchy, so they can't be realized (that's what gives the XID). - the plugin process talks to the browser process through the renderer process to create/destroy the gtksockets, because the plugin doesn't know which renderer it's talking to. We need a bit more plumbing to be able to have direct IPC. - some code is duplicated between chrome and test_shell. We should probably factor it, but I'm not sure where the common part should live. Review URL: http://codereview.chromium.org/146078 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19983 0039d316-1c4b-4281-b951-d872f2087c98
* mac/linux: rework plugin channel file descriptor creationevan@chromium.org2009-06-271-11/+1
| | | | | | | | | | | | This CL fixes a bug where the same renderer could open several channels to the same plugin process, which end up having the same name. This CL makes it that there is only one channel for each (plugin, renderer) pair, just like on Windows. The socketpair is created in the plugin process (which can ensure that only one channel per renderer gets created), and sends the renderer side through the browser process. Note: this should essentially be a noop on Windows. Review URL: http://codereview.chromium.org/149062 Patch from Antoine Labour <piman@google.com>. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19448 0039d316-1c4b-4281-b951-d872f2087c98
* posix: two related changes to make plugin IPC work on POSIX.evan@chromium.org2009-06-221-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | [re-retry, seeing if reliability bots like it] * use a new ChannelHandle type when passing IPC channels over IPC The current POSIX code assumes that one end of a channel is always a new child process (a renderer). For plugins we need to be able to construct channels between each of the browser, plugin, and renderer. This change augments the messages related to creating channels to allow passing in a base::FileDescriptor containing the socket. The intent is that the browser process, as the initial interchange between plugin and renderer, creates the socketpair() on their behalf and hands each their respective end of the connection. * register channel endpoint names in the global pipe map The plugin code assumes it can map from a string to a channel endpoint at basically any time. So whenever we get a channel endpoint over IPC, we install it in a global map of channel endpoints. Review URL: http://codereview.chromium.org/113157 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18950 0039d316-1c4b-4281-b951-d872f2087c98
* Revert "posix: two related changes to make plugin IPC work on POSIX."evan@chromium.org2009-06-221-15/+0
| | | | | | | | This looks like it might be to blame for reliability test failures, so I'm trying it out. This reverts commit r18888. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18905 0039d316-1c4b-4281-b951-d872f2087c98
* posix: two related changes to make plugin IPC work on POSIX.evan@chromium.org2009-06-201-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | [retry, fix windows compile failure] * use a new ChannelHandle type when passing IPC channels over IPC The current POSIX code assumes that one end of a channel is always a new child process (a renderer). For plugins we need to be able to construct channels between each of the browser, plugin, and renderer. This change augments the messages related to creating channels to allow passing in a base::FileDescriptor containing the socket. The intent is that the browser process, as the initial interchange between plugin and renderer, creates the socketpair() on their behalf and hands each their respective end of the connection. * register channel endpoint names in the global pipe map The plugin code assumes it can map from a string to a channel endpoint at basically any time. So whenever we get a channel endpoint over IPC, we install it in a global map of channel endpoints. Review URL: http://codereview.chromium.org/113157 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18888 0039d316-1c4b-4281-b951-d872f2087c98
* Revert "posix: two related changes to make plugin IPC work on POSIX."evan@chromium.org2009-06-191-15/+0
| | | | | | This reverts commit r18850, as it had a compile failure. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18851 0039d316-1c4b-4281-b951-d872f2087c98
* posix: two related changes to make plugin IPC work on POSIX.evan@chromium.org2009-06-191-0/+15
| | | | | | | | | | | | | | | | | | | | | | * use a new ChannelHandle type when passing IPC channels over IPC The current POSIX code assumes that one end of a channel is always a new child process (a renderer). For plugins we need to be able to construct channels between each of the browser, plugin, and renderer. This change augments the messages related to creating channels to allow passing in a base::FileDescriptor containing the socket. The intent is that the browser process, as the initial interchange between plugin and renderer, creates the socketpair() on their behalf and hands each their respective end of the connection. * register channel endpoint names in the global pipe map The plugin code assumes it can map from a string to a channel endpoint at basically any time. So whenever we get a channel endpoint over IPC, we install it in a global map of channel endpoints. Review URL: http://codereview.chromium.org/113157 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18850 0039d316-1c4b-4281-b951-d872f2087c98
* Fix regression from r11509 which caused each plugin instance to have its own ↵jam@chromium.org2009-06-051-2/+5
| | | | | | | | | | IPC channel (doh!). BUG=119052 TEST=covered by ui test that Amit added Review URL: http://codereview.chromium.org/119158 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17712 0039d316-1c4b-4281-b951-d872f2087c98
* ipc: use strings, not wstrings for channel ids.evan@chromium.org2009-06-041-1/+1
| | | | | | | | | | They're ASCII anyway. TEST=covered by existing tests Review URL: http://codereview.chromium.org/119131 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17682 0039d316-1c4b-4281-b951-d872f2087c98
* Added support for constructor calls in the NPAPI.sgjesse@chromium.org2009-05-271-0/+5
| | | | | | | | | | | | | | | | | The LiveConnect test cases at http://java.sun.com/javase/6/webnotes/6u10/plugin2/liveconnect/LiveConnectTests/ now pass for Chromium. Parts of this change is rather mechanical, and leaves room for some refactoring afterwards. Merged the implementation of testConstruct and the "objectPointer" property from WebKit\WebKitTools\DumpRenderTree\TestNetscapePlugIn.subproj\TestObject.cpp to the Chromium TestObject.cpp for the layout test LayoutTests\plugins\netscape-construct.html pass. BUG=http://crbug.com/3285 BUG=http://crbug.com/10354 TEST=http://java.sun.com/javase/6/webnotes/6u10/plugin2/liveconnect/LiveConnectTests/ TEST=LayoutTests\plugins\netscape-construct.html Review URL: http://codereview.chromium.org/113823 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16979 0039d316-1c4b-4281-b951-d872f2087c98
* Rename |policy_url| to |first_party_for_cookies|. This now matches the ↵abarth@chromium.org2009-05-231-2/+2
| | | | | | | | | | | | WebKit name for this piece of data. R=jackson BUG=None TEST=No behavior change Review URL: http://codereview.chromium.org/115743 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16843 0039d316-1c4b-4281-b951-d872f2087c98
* CPAPI gears drag drop and renderer IPC.michaeln@google.com2009-05-221-0/+11
| | | | | | | | | | | | | | | CPAPI (0.10) functions for gears drag drop; one to extract thedrag type/data given an NPObject *event, one to override thedrop effect (drag cursor). Gears drag drop API receives a browser event as an NPObject* sothe event is untrusted. Provide IPC calls to the renderer sogears can pass the event to renderer/V8 for checking, prior todrag type/data extraction, or the setting of the drop effect. Original patch by Noel Gordon via: http://codereview.chromium.org/99240 BUG=7995 TEST=none Review URL: http://codereview.chromium.org/112056 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16808 0039d316-1c4b-4281-b951-d872f2087c98
* Add events to windowless plugins on linux. This CL also refactors the eventevan@chromium.org2009-05-221-2/+2
| | | | | | | | | | | | | communication between WebPlugin and WebPluginDelegate, to use a cross-platform message based on WebInputEvent. BUG=8202 TEST=A lot of manual testing on Linux and Windows, with Flash plugins and a custom plugin that dumps events on Linux. Review URL: http://codereview.chromium.org/115330 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16692 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting 15986.michaeln@google.com2009-05-131-11/+0
| | | | | | Review URL: http://codereview.chromium.org/113359 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15987 0039d316-1c4b-4281-b951-d872f2087c98
* CPAPI gears drag drop and renderer IPC....michaeln@google.com2009-05-131-0/+11
| | | | | | | | | | | | | | | | | | | | | | CPAPI (0.10) functions for gears drag drop; one to extract the drag type/data given an NPObject *event, one to override the drop effect (drag cursor). Gears drag drop API receives a browser event as an NPObject* so the event is untrusted. Provide IPC calls to the renderer so gears can pass the event to renderer/V8 for checking, prior to drag type/data extraction, or the setting of the drop effect. V8 event checking is a TODO(noel), http://mondrian/10947778 for the CPAPI (0.10) change submitted to gears. BUG=7995 Original patch by Noel Gordon via: http://codereview.chromium.org/99240 Review URL: http://codereview.chromium.org/115280 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15986 0039d316-1c4b-4281-b951-d872f2087c98
* linux (and some posix): multiprocess plugins compiling.evan@chromium.org2009-04-231-2/+2
| | | | | | | | | | | | | | | | | | | The goal of this change is to *not* make any behavioral change, but to instead just get all the plugin-related files linking on Linux with a bunch of NOTIMPLEMENTED()s in the appropriate places. It's enormous enough already without any refactorings or new features. Changes include: - Lots of gcc warning fixes. - Use portable replacements for Windows-specific functions (_strdup, etc.). - Use TransportDIB instead of just shared memory in the plugin messaging. Note that this is not fleshed out on Linux and on Windows it just hacks in the existing handles so there should be no functional change. - Fix --plugin-launcher to use cross-platform APIs. Review URL: http://codereview.chromium.org/79020 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14338 0039d316-1c4b-4281-b951-d872f2087c98
* Fix hang seen in plugin process because plugin creation ended up having to ↵jam@chromium.org2009-04-211-3/+4
| | | | | | | | | | wait on UI thread. Instead of using sync messages, the plugin hwnd is initially parented to the RenderWidgetHost's HWND. It's then lazily reparented to an intermediate HWND on the UI thread when it comes time to move it. BUG=10711 TEST=added regression tests, but testers please confirm plugins on top video sites are placed correctly. Review URL: http://codereview.chromium.org/67285 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14137 0039d316-1c4b-4281-b951-d872f2087c98
* Revert "Move IPC code to ipc/"agl@chromium.org2009-04-031-1/+1
| | | | | | | This reverts commit r13062 which, unsurprisingly, broke the build. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13063 0039d316-1c4b-4281-b951-d872f2087c98
* Move IPC code to ipc/agl@chromium.org2009-04-031-1/+1
| | | | | | | (No review URL: Rietvelt couldn't cope) git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13062 0039d316-1c4b-4281-b951-d872f2087c98
* Port plugin messages.jam@chromium.org2009-04-011-16/+23
| | | | | | Review URL: http://codereview.chromium.org/49050 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12928 0039d316-1c4b-4281-b951-d872f2087c98
* Refactor plugin process code which checks with the browser process before ↵jam@chromium.org2009-03-271-4/+8
| | | | | | | | | | | shutdown, to avoid races in which the browser process thinks the process is fine to use while it's shutting down. I also removed PluginProcess/WorkerProcess since they didn't have any code in them now. I removed the plugin process code which waits 10 seconds before shutting itself down. That was a premature optimization, since testing with/without this didn't show any difference (see http://www/~jabdelmalek/chrome/test/plugins/processes.html). In both cases, the plugin on a page would get recreated in less than 100ms, even with reusing or starting a plugin process from scratch. We already spawn new renderer processes on back and forth if it's a different origin, and the plugin will be in the cache anyways. Review URL: http://codereview.chromium.org/53091 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12703 0039d316-1c4b-4281-b951-d872f2087c98
* Expose whether we're in private browsing mode to plugins.I chose to ↵jam@chromium.org2009-03-261-1/+2
| | | | | | | | | implement this for multi-process mode only and not --single-process or --in-process-plugins, since I wanted to send this data from the browser process, not the renderer (in case it's exploited). BUG=158 Review URL: http://codereview.chromium.org/52037 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12588 0039d316-1c4b-4281-b951-d872f2087c98
* Stop having renderers use both pids and a monotonically increasing ↵jam@chromium.org2009-03-121-7/+2
| | | | | | | | "host_id". This allows ResourceDispatcher to be used by child processes other than renderers. I've done minor related cleanup on the way to make the code simpler. Review URL: http://codereview.chromium.org/42054 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11509 0039d316-1c4b-4281-b951-d872f2087c98
* NO CODE CHANGEdeanm@chromium.org2009-03-101-1/+0
| | | | | | | | | Normalize end of file newlines in chrome/. All files end in a single newline. Review URL: http://codereview.chromium.org/42015 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11331 0039d316-1c4b-4281-b951-d872f2087c98
* Commit just the changes to make creating new IPC channel types easier.jam@chromium.org2009-02-041-5/+5
| | | | | | | | TBR=mpcomplete Review URL: http://codereview.chromium.org/21052 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9167 0039d316-1c4b-4281-b951-d872f2087c98
* Revert my change to get the tree green. Not sure why the tests became ↵jam@chromium.org2009-02-041-5/+5
| | | | | | | | | | flaky. I'll try to check them in again but in smaller chunks tomorrow. TBR=mpcomplete Review URL: http://codereview.chromium.org/21039 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9132 0039d316-1c4b-4281-b951-d872f2087c98
* Make it easier/less work/less error-prone to create new IPC channel types ↵jam@chromium.org2009-02-041-5/+5
| | | | | | | | (i.e. renderer/plugin).Instead of having each message file include the internal one several times with different ifdefs, move that logic to ipc_message_macros.h. Also make the message class starting IDs come from an enum to ensure we don't use a value twice. I simplified the logging code a bit so we don't need X_messages.cc files.Clean up places that we were doing manual packing/unpacking. Most of this was in the automation code. I added a few new template functions to make it convenient to read the parameters from a message, and updated the code to use them.I also removed unnecessary includes of render/plugin_messages.h from headers to speed up compiling.I moved the traits of IPC structs beside the struct definition to make it more apparent what's going on, so we avoid people modifying the struct and forgetting to update the traits.Amit: please look at chrome/test/automation/tab_proxy.ccMarc-Antoine: chrome/browser/printing/*Matt: the rest Review URL: http://codereview.chromium.org/20015 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9123 0039d316-1c4b-4281-b951-d872f2087c98
* Move proxy resolve requests out of plugin/renderer process, and into the ↵ericroman@google.com2009-01-311-1/+2
| | | | | | | | browser. Review URL: http://codereview.chromium.org/14142 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9006 0039d316-1c4b-4281-b951-d872f2087c98
* Fix a timing issue that caused gears to fail to load sometimes.mpcomplete@google.com2009-01-211-5/+0
| | | | | | | | BUG=http://b/issue?id=1559007 BUG=http://code.google.com/p/chromium/issues/detail?id=4219 Review URL: http://codereview.chromium.org/18604 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8417 0039d316-1c4b-4281-b951-d872f2087c98
* Improve scrolling performance when there are many windowed plugins in a page.jam@chromium.org2009-01-161-3/+10
| | | | | | | | This works by parenting windowed plugins with an HWND that's hosted in the browser process, so that no synchronous cross process messages are used when scrolling. BUG=5428 Review URL: http://codereview.chromium.org/18082 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8239 0039d316-1c4b-4281-b951-d872f2087c98
* Misc proxy service changes.ericroman@google.com2008-12-101-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (1) Changed the proxy service ownership model -- rather than being a detail of the HTTP stack, it is now a dependency owned by UrlRequestContext. - ProxyService is owned by UrlRequestContext (before was HttpNetworkSession) - ProxyResolver is owned by ProxyService (before was HttpNetworkSession) Being able to share the proxy service is needed in several places, including incognito mode http context (http://crbug.com/3564), and for proxy resolving in the new FTP stack. (2) Added an IPC for getting of the ProxyResolverWinHttp dependency in the plugin process. Not hooked up yet, but intent is to route the proxy resolve requests through the browser process. (3) Changed some unit tests which were depending on the system proxy settings (this was a sideffect of their calling HttpNetworkLayer::CreateFactory(NULL)). (4) Moved the first-time ProxyService::UpdateConfig out of the constructor and into the initial request. Done to avoid startup perf regressions, since the ProxyService construction is now done earlier (on the startup critical path). BUG=3564 Review URL: http://codereview.chromium.org/12938 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6693 0039d316-1c4b-4281-b951-d872f2087c98
* Fixing build bustage. Adding files which were part of the original changeananta@chromium.org2008-12-051-0/+2
| | | | | | | | | | branch r6396, which was reverted partially. TBR=jam Review URL: http://codereview.chromium.org/13215 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6460 0039d316-1c4b-4281-b951-d872f2087c98
* Don't cancel the original manual data stream request when the plugin invokesananta@chromium.org2008-12-041-2/+0
| | | | | | | | | | | | | | | | | | | | NPN_RequestRead to initiate seekable byte range requests on the stream. While the contract on the plugins part is not fully clear from the mozilla docs, this is what Firefox does. This also improves performance greatly as the manual data stream already has most of the data which the plugin requests anyway. I verified this with large PDF files around 14-15MB. We are twice as faster with this fix. This fixes http://code.google.com/p/chromium/issues/detail?id=5009, which is an issue with the PDF file not loading at times. The problem also occurs at times in Firefox when we set breakpoints and thus slow down the operation. The Reader plugin displays its UI in child windows on a separate thread in the plugin process. These are parented to the plugin window which lives on the plugin thread. The plugin thread unfortunately is treated as an IO thread by the plugin and it uses the SendMessage API to send messages to the plugin thread and back. If the plugin fails to receive data for the PDF file in a reasonable time, it just destroys the PDF window hierarchy causing this issue. Handing the data off the manual data stream along with the byte range data speeds up the whole operation and thus avoids this issue to a great extent. Bug=5009 R=jam Review URL: http://codereview.chromium.org/12960 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6396 0039d316-1c4b-4281-b951-d872f2087c98
* Add Terminate() to the Process object, have RenderProcessHost use this to ↵brettw@google.com2008-11-141-2/+2
| | | | | | | | | | 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
* Patch by Thatcher Ulrich <tulrich@google.com>.ojan@google.com2008-10-091-1/+2
| | | | | | | | | | | | | | | Implement "iframe shim" behavior for windowed plugins. In FF and IE on windows, iframes are implemented as native HWNDs. This has the side effect that iframes display on top of windowed plugins. This side effect has long been known as a workaround for allowing HTML elements to appear above plugin content. BUG=1788 Review URL: http://codereview.chromium.org/7032 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@3137 0039d316-1c4b-4281-b951-d872f2087c98
* Attempt 2 at landing this patch. It broke the Mac/linux builds. Fix for now isananta@chromium.org2008-10-091-1/+2
| | | | | | | | | | | | | | | | | | | | | | to add the offending code in np_v8object.cpp in a ifdef OS_WIN This fixes http://code.google.com/p/chromium/issues/detail?id=2472, which is an issue with popups displayed by the flash plugin in response to a user click, getting blocked. The plugin invokes NPN_Evaluate to execute the javascript. It also invokes the NPN_PushPopupEnabledState/NPN_PopupEnabledState API's to set the popup enabled stack for the duration of the call. The fix is to add the plumbing in NPN_Evaluate to pass in a flag indicating whether popups are allowed for the duration of the call. Bug=2472 R=jam Review URL: http://codereview.chromium.org/6379 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@3119 0039d316-1c4b-4281-b951-d872f2087c98
* Revert r3074 due to Mac build bustagemark@chromium.org2008-10-091-2/+1
| | | | | | Review URL: http://codereview.chromium.org/6378 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@3088 0039d316-1c4b-4281-b951-d872f2087c98
* This fixes http://code.google.com/p/chromium/issues/detail?id=2472, whichananta@chromium.org2008-10-081-1/+2
| | | | | | | | | | | | | | | | | | is an issue with popups displayed by the flash plugin in response to a user click, getting blocked. The plugin invokes NPN_Evaluate to execute the javascript. It also invokes the NPN_PushPopupEnabledState/NPN_PopupEnabledState API's to set the popup enabled stack for the duration of the call. The fix is to add the plumbing in NPN_Evaluate to pass in a flag indicating whether popups are allowed for the duration of the call. Bug=2472 Review URL: http://codereview.chromium.org/6562 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@3074 0039d316-1c4b-4281-b951-d872f2087c98
* Fix painting problem with transparent plugins because plugins were ignoring ↵jam@chromium.org2008-10-011-3/+13
| | | | | | | | | | | | | | | the alpha channel sometimes. This change introduces another buffer which holds the background image for transparent plugins. Before painting these plugins, their backing store is overwritten with the background data. This change also uses an ACK from the renderer to figure out when it can paint, similar to how the renderer does it, which gives us throttling and also doesn't lead to painting when the tab is hidden. Review URL: http://codereview.chromium.org/5040 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2744 0039d316-1c4b-4281-b951-d872f2087c98
* Desynchronize windowless plugin painting. This greatly improves the paintingjam@chromium.org2008-09-221-11/+4
| | | | | | | | performance when there are multiple plugins, or when scrolling. Review URL: http://codereview.chromium.org/3133 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2459 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-01-20 08:54:24 +0000