summaryrefslogtreecommitdiffstats
path: root/chrome/plugin
Commit message (Collapse)AuthorAgeFilesLines
* linux: add windowless plugin plumbingpiman@google.com2009-07-222-4/+32
| | | | | | | Review URL: http://codereview.chromium.org/159128 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21250 0039d316-1c4b-4281-b951-d872f2087c98
* Revert r21117 as it caused reliability failures.estade@chromium.org2009-07-213-19/+52
| | | | | | | | | | Also included in this revert: r21165, r21180, and a couple valgrind suppression edits TBR=huanr Review URL: http://codereview.chromium.org/155876 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21216 0039d316-1c4b-4281-b951-d872f2087c98
* Switch the first thread in a child process to be the main thread, and make ↵jam@chromium.org2009-07-203-52/+19
| | | | | | | | the IO thread be the second thread. The change is needed for plugins on mac. Review URL: http://codereview.chromium.org/149558 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21117 0039d316-1c4b-4281-b951-d872f2087c98
* Fixes a crash in the plugin process caused by the XStandard plugin passing ↵ananta@chromium.org2009-07-171-0/+24
| | | | | | | | | | | | | | in a NULL NPObject to NPN_HasMethod. I checked out Firefox's implementation and they check for NULL NPObjects in all functions except NPN_Evaluate and NPN_SetException. Fix is to emulate Firefox behavior. Fixes http://code.google.com/p/chromium/issues/detail?id=16900 Bug=16900 Review URL: http://codereview.chromium.org/155628 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20940 0039d316-1c4b-4281-b951-d872f2087c98
* Remove the carbon event dispatcher from the main thread of the plugin processamanda@chromium.org2009-07-131-48/+0
| | | | | | | | | | | | and replace it with a pump for null events on the plugin thread. This removes a deadlock that the previous code inadvertently created, and is a much more focused solution to the problem. BUG=10809 TEST=none Review URL: http://codereview.chromium.org/155439 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20528 0039d316-1c4b-4281-b951-d872f2087c98
* Wire up windowless plugins. Mostly Mac related, some crossamanda@chromium.org2009-07-115-29/+159
| | | | | | | | | | 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: move gtk_init to the right threadpiman@google.com2009-07-102-16/+21
| | | | | | | | | In the plugin process, gtk_init needs to be called from the UI thread (PluginThread) not the main thread (PluginMain) which is an IO thread. Review URL: http://codereview.chromium.org/149424 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20340 0039d316-1c4b-4281-b951-d872f2087c98
* Start using WebCursorInfo from the WebKit API. WebCursorInfo is adarin@google.com2009-07-081-1/+6
| | | | | | | | | | | | | | | | lightweight struct containing a description of a cursor that the embedder should render. WebCursor still exists. Instead of WebCursor initializing from a PlatformCursor, it now initializes from a WebCursorInfo. TEST=none BUG=10039 R=jam Review URL: http://codereview.chromium.org/155172 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20194 0039d316-1c4b-4281-b951-d872f2087c98
* Add the page url to plugin crashes to aid debugging.jam@chromium.org2009-07-0810-44/+108
| | | | | | Review URL: http://codereview.chromium.org/155238 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20191 0039d316-1c4b-4281-b951-d872f2087c98
* Revert change 20173 because it breaks the ui_tests, plugin_testsnsylvain@chromium.org2009-07-0810-103/+44
| | | | | | | | and most likely some page cyclers. Review URL: http://codereview.chromium.org/155236 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20180 0039d316-1c4b-4281-b951-d872f2087c98
* Add the page url to plugin crashes to aid debugging.jam@chromium.org2009-07-0810-44/+103
| | | | | | Review URL: http://codereview.chromium.org/149305 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20173 0039d316-1c4b-4281-b951-d872f2087c98
* linux: fix renderer/plugin crash when loading multiple pages with pluginspiman@google.com2009-07-081-1/+2
| | | | | | | | | | Currently we crash if one renderer has a plugin and another one has a plugin that gets destroyed, and started again (e.g. reload). We get away with reload on a single page currently because the process gets torn down. This properly cleans up the socket and channel mapping on both sides, so it can be restarted. Review URL: http://codereview.chromium.org/155174 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20112 0039d316-1c4b-4281-b951-d872f2087c98
* linux: OOP windowed pluginsevan@chromium.org2009-07-074-21/+37
| | | | | | | | | | | | | | 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-064-37/+21
| | | | | | 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-064-21/+37
| | | | | | | | | | | | 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
* Move Emf class to the printing library. Also creates a platform agnostic ↵sverrir@google.com2009-07-061-10/+7
| | | | | | | | | | | NativeMetafile definition to ease platform porting. BUG=none TEST=none (No functional change) Review URL: http://codereview.chromium.org/149181 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19943 0039d316-1c4b-4281-b951-d872f2087c98
* linux: only create browser-side plugin container after plugin requests itevan@chromium.org2009-06-301-0/+5
| | | | | | | | | | | | | | | | | | | | | | On Windows, windowed plugins are parented in a two-stage process: initially, the plugin is parented to the render view, then later it's reparented to a special per-plugin window. On Linux, plugin embedding always needs a special per-plugin window before it can be initialized. So there's no way to do the two-stage initialization process, and we only want to construct the browser-side plugin container for windowed plugins after the plugin requests it. Plumbing this through the WebPlugin interface will also allow us to side-route this request for window creation out to the browser process in the multi-process case. BUG=15421 TEST=plugins still work in test_shell Review URL: http://codereview.chromium.org/150034 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19602 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting 19560. This caused a bunch of plugin-related unittest failures on ↵glen@chromium.org2009-06-301-5/+0
| | | | | | | | Windows. Review URL: http://codereview.chromium.org/150088 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19573 0039d316-1c4b-4281-b951-d872f2087c98
* linux: only create browser-side plugin container after plugin requests itevan@chromium.org2009-06-291-0/+5
| | | | | | | | | | | | | | | | | | | | | | On Windows, windowed plugins are parented in a two-stage process: initially, the plugin is parented to the render view, then later it's reparented to a special per-plugin window. On Linux, plugin embedding always needs a special per-plugin window before it can be initialized. So there's no way to do the two-stage initialization process, and we only want to construct the browser-side plugin container for windowed plugins after the plugin requests it. Plumbing this through the WebPlugin interface will also allow us to side-route this request for window creation out to the browser process in the multi-process case. BUG=15421 TEST=plugins still work in test_shell Review URL: http://codereview.chromium.org/150034 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19560 0039d316-1c4b-4281-b951-d872f2087c98
* mac/linux: rework plugin channel file descriptor creationevan@chromium.org2009-06-274-27/+59
| | | | | | | | | | | | 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
* linux plugins: eliminate GtkWidget* from plugin processevan@chromium.org2009-06-262-4/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | [retry with mac hopefully fixed this time] GtkWidget* (and its wrapper, gfx::NativeView) only work within a single process. Plugins already work with a lower-level type that works across processes -- an X Window id. The parent of a plugin is an HWND on windows, but it's an X Window id on X. So we introduce a new typedef wrapping that and push it through all the places in the code that needs it. Since we no longer have a GtkSocket in the WebPluginDelegateImpl, we need to do a bit more work in the WebViewDelegate (aka the browser process in the multiproc world). We also need the plugin host (the browser) to track the GtkSockets that are hosting the plugin, as well as destroy them when necessary. To do this we require the plugin owner to grab the plug-removed signal rather than putting its handler in GtkPluginContainer; this is the way it worked before I'd refactored into GtkPluginContainer so it shouldn't be so bad. This change still only works in test_shell, but the refactoring should translate to the multiprocess case pretty easily. Review URL: http://codereview.chromium.org/146009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19387 0039d316-1c4b-4281-b951-d872f2087c98
* Revert all of my patches from today.evan@chromium.org2009-06-262-10/+4
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19328 0039d316-1c4b-4281-b951-d872f2087c98
* linux plugins: eliminate GtkWidget* from plugin processevan@chromium.org2009-06-262-4/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | GtkWidget* (and its wrapper, gfx::NativeView) only work within a single process. Plugins already work with a lower-level type that works across processes -- an X Window id. The parent of a plugin is an HWND on windows, but it's an X Window id on X. So we introduce a new typedef wrapping that and push it through all the places in the code that needs it. Since we no longer have a GtkSocket in the WebPluginDelegateImpl, we need to do a bit more work in the WebViewDelegate (aka the browser process in the multiproc world). We also need the plugin host (the browser) to track the GtkSockets that are hosting the plugin, as well as destroy them when necessary. To do this we require the plugin owner to grab the plug-removed signal rather than putting its handler in GtkPluginContainer; this is the way it worked before I'd refactored into GtkPluginContainer so it shouldn't be so bad. This change still only works in test_shell, but the refactoring should translate to the multiprocess case pretty easily. Review URL: http://codereview.chromium.org/146009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19320 0039d316-1c4b-4281-b951-d872f2087c98
* posix: two related changes to make plugin IPC work on POSIX.evan@chromium.org2009-06-225-9/+46
| | | | | | | | | | | | | | | | | | | | | | | | [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-225-46/+9
| | | | | | | | 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-205-9/+46
| | | | | | | | | | | | | | | | | | | | | | | | [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-195-46/+9
| | | | | | 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-195-9/+46
| | | | | | | | | | | | | | | | | | | | | | * 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 Gears crash after making PluginThread::current() only work on that thread.jam@chromium.org2009-06-171-5/+6
| | | | | | Review URL: http://codereview.chromium.org/126244 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18563 0039d316-1c4b-4281-b951-d872f2087c98
* Switch child threads so that current() only works on the correct thread and ↵jam@chromium.org2009-06-151-2/+7
| | | | | | | | the correct process. Review URL: http://codereview.chromium.org/126086 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18409 0039d316-1c4b-4281-b951-d872f2087c98
* Refactor the PlatformContext layer to have only one class.brettw@chromium.org2009-06-142-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Previously we had three classes of PlatformCanvas*, one for each platform. Then we had a typedef of PlatformContext to PlatformCanvas[Mac|Win|Linux] for the specific platform. This means that it was almost impossible to forward-declare PlatformCanvas and there were a bunch of unnecessary includes of platform_canvas.h in header files. This change makes there be only one platform_canvas.h header with ifdefs, which removes a decent amount of duplicated code. There is a platform-independent file, and one platform-dependent file of platform_canvas for each platform. I also renamed PlatformDevice[Mac|Win|Linux] to PlatformDevice, althouth in this case I kept the separate headers since there was much less overlap. I also broke out CanvasPaint into separate headers so this template doesn't need to be included all over the project (only a couple of files actually need it). Review URL: http://codereview.chromium.org/125109 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18363 0039d316-1c4b-4281-b951-d872f2087c98
* Linux: refactor zygote supportagl@chromium.org2009-06-121-0/+3
| | | | | | | | | | | | | | | | | | | http://code.google.com/p/chromium/wiki/LinuxZygote * Move Chrome specific bits out of base * Move away from the idea of reserved file descriptors (which don't really work with zygotes) * Load resources before forking renderers (means that we don't need communication between the zygote process and the renderers) * Make sure that gdb works against the browser again * Make sure that we have different ASLR between the renderers and the browser. http://codereview.chromium.org/119335 (This is a reland. First landed in r18109, reverted in r18112.) git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18291 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 18109, 18111: Windows UI tests failed.agl@chromium.org2009-06-101-3/+0
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18112 0039d316-1c4b-4281-b951-d872f2087c98
* Linux: refactor zygote supportagl@chromium.org2009-06-101-0/+3
| | | | | | | | | | | | | | | | | | http://code.google.com/p/chromium/wiki/LinuxZygote * Move Chrome specific bits out of base * Move away from the idea of reserved file descriptors (which don't really work with zygotes) * Load resources before forking renderers (means that we don't need communication between the zygote process and the renderers) * Make sure that gdb works against the browser again * Make sure that we have different ASLR between the renderers and the browser. http://codereview.chromium.org/119335 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18109 0039d316-1c4b-4281-b951-d872f2087c98
* Fix regression from r11509 which caused each plugin instance to have its own ↵jam@chromium.org2009-06-056-10/+11
| | | | | | | | | | 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-044-8/+8
| | | | | | | | | | 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
* Convert most of the chrome .lib files to gyp generation:sgk@chromium.org2009-06-041-231/+0
| | | | | | | | | automation.lib, common.lib, debugger.lib, plugin.lib, renderer.lib. BUG=none TEST=none Review URL: http://codereview.chromium.org/118254 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17675 0039d316-1c4b-4281-b951-d872f2087c98
* Fix browser hang due to plugin deadlockamit@chromium.org2009-06-032-2/+3
| | | | | | | | | | | | | | | | | | | | | This involves two plugin instances with second instance making sync calls to the renderer while the first one is still servicing an incoming sync request. Our logic to unblock the renderer during the sync call fails since the 'in_dispatch_' counter is maintained per plugin channel (each plugin instance uses its own separate channel). Making 'in_dispatch_' counter static member of PluginChannelBase fixes this deadlock. Added a new NPAPI UI test for this scenario. BUG=12624 TEST=MultipleInstancesSyncCalls Review URL: http://codereview.chromium.org/119052 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17492 0039d316-1c4b-4281-b951-d872f2087c98
* Reduce header dependencies in net/phajdan.jr@chromium.org2009-05-291-0/+1
| | | | | | | | TEST=none Review URL: http://codereview.chromium.org/115870 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17178 0039d316-1c4b-4281-b951-d872f2087c98
* Added support for constructor calls in the NPAPI.sgjesse@chromium.org2009-05-274-3/+94
| | | | | | | | | | | | | | | | | 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
* Make sure that seekable streams are removed from the list of resource ↵ananta@chromium.org2009-05-232-0/+16
| | | | | | | | | | | | | | | | | | | | clients maintained by WebPluginProxy. The PluginStreamUrl object ensures that it notifies the webplugin object that it is being deleted in its destructor. The other change is to remove the call to CancelRequest in WebPluginDelegateImpl::CreateResourceClient for seekable streams, as this call does not do anything for manual streams created with a resource id of -1. In any case for byte range requests, receiving a new response does not mean that earlier requests should be cancelled. This fixes bug http://code.google.com/p/chromium/issues/detail?id=12445 BUG=12445 Review URL: http://codereview.chromium.org/113772 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16828 0039d316-1c4b-4281-b951-d872f2087c98
* CPAPI gears drag drop and renderer IPC.michaeln@google.com2009-05-223-0/+99
| | | | | | | | | | | | | | | 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-222-7/+12
| | | | | | | | | | | | | 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
* ChromeCanvas->gfx::Canvasben@chromium.org2009-05-151-1/+1
| | | | | | | | | | | Rename files too. TBR=brettw http://crbug.com/11387 Review URL: http://codereview.chromium.org/113443 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16148 0039d316-1c4b-4281-b951-d872f2087c98
* linux: we actually already had a bug on file for this NOTIMPLEMENTED.evan@chromium.org2009-05-141-1/+4
| | | | | | Review URL: http://codereview.chromium.org/115367 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16082 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting 15986.michaeln@google.com2009-05-133-99/+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-133-0/+99
| | | | | | | | | | | | | | | | | | | | | | 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
* Move win_util.h from common to app.ben@chromium.org2009-05-083-3/+8
| | | | | | | | http://crbug.com/11387 Review URL: http://codereview.chromium.org/113169 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15694 0039d316-1c4b-4281-b951-d872f2087c98
* Move chrome_canvas to app/gfxben@chromium.org2009-05-061-1/+1
| | | | | | | | http://crbug.com/11387 Review URL: http://codereview.chromium.org/113011 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15361 0039d316-1c4b-4281-b951-d872f2087c98
* Replace all occurrances of WebContents with TabContents.brettw@chromium.org2009-05-041-1/+1
| | | | | | Review URL: http://codereview.chromium.org/99177 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15194 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-01-31 10:09:21 +0000