summaryrefslogtreecommitdiffstats
path: root/webkit/glue/webplugin_impl.h
Commit message (Collapse)AuthorAgeFilesLines
* Fix plugin window sticking around when parent became invisible. Added test ↵jam@chromium.org2009-05-101-6/+0
| | | | | | | | | | | | for all different scenarios. Note I grabbed the plugin hwnd and manually checked it instead of looking for callbacks from the plugin's SetWindow since the latter isn't called if the visibility changes. BUG=1842096 TEST=regression test included, test http://chromedashboard per bug Review URL: http://codereview.chromium.org/115169 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15732 0039d316-1c4b-4281-b951-d872f2087c98
* Fix hang seen in plugin process because plugin creation ended up having to ↵jam@chromium.org2009-04-211-1/+2
| | | | | | | | | | 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
* Fix a painting problem observed with windowless flash plugins, when they are ↵ananta@chromium.org2009-04-161-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | initially created with a zero clip rect, which eventually changes to a non zero clip rect. We don't send over geometry updates to the plugin if the window dimensions don't change, which is true in this case. This causes the plugin process to not send over paints to the renderer process as the plugin clip rect remains zero. The fix based on a discussion with John is to remove the check for whether the plugin dimensions changed and always send over the update geometry IPC to the plugin, where we do check whether these rects changed before calling the underlying plugin. This fixes bug http://code.google.com/p/chromium/issues/detail?id=10536 I am trying to come up with a unit test for this case. Will add it to this CB or submit those as a separate CB. Bug=10536 Review URL: http://codereview.chromium.org/73071 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13822 0039d316-1c4b-4281-b951-d872f2087c98
* Port plugin messages.jam@chromium.org2009-04-011-6/+9
| | | | | | Review URL: http://codereview.chromium.org/49050 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12928 0039d316-1c4b-4281-b951-d872f2087c98
* Expose whether we're in private browsing mode to plugins.I chose to ↵jam@chromium.org2009-03-261-0/+3
| | | | | | | | | 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
* Report the plugin position to windowed plugins as (0,0)jam@chromium.org2009-03-261-1/+1
| | | | | | | | | | . the NPAPI documentation says it should be reported relative to the parent HWND, which is the plugin's coordinates on the page. This assumption breaks in Chrome because we have an intermediate HWND. I've tested on a bunch of pages to see if this change causes regressions, if we find any in the future we can reconsider this. BUG=6742 Review URL: http://codereview.chromium.org/42626 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12587 0039d316-1c4b-4281-b951-d872f2087c98
* The street view in Google maps, which is implemented with a windowed flash ↵ananta@chromium.org2009-03-201-13/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | plugin would draw over the iframe DOM element, effectively hiding it. This is handled by our IFrame shim geometry calculation, where we subtract the rect of any IFrame above the plugin in the ZOrder from the plugin rect. Webkit calls Widget::setFrameRect at various times, during layout/size changes/paints, etc. The reason this bug showed up, was due to an optimization in our setFrameRect implementation, where we would bail out if the rect passed in was the same size as the current plugin rect. Basically the IFrame appears above the plugin in the ZOrder much later, which causes us to return without sending over the cutout rects to the browser when it moves the plugin windows. Fix is to move the rects equality check to WebPluginImpl::setFrameRect, where we don't send over the UpdateGeometry IPC to the plugin process if the rects are the same. WebPluginImpl used to implement the webkit Widget interface a long time ago. This is no longer the case. So some of the functions don't need to be virtual anymore. I also made this change. This fixes bug http://b/issue?id=1722236 and http://code.google.com/p/chromium/issues/detail?id=8858 Bug=1722236,8858 Review URL: http://codereview.chromium.org/42413 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12179 0039d316-1c4b-4281-b951-d872f2087c98
* Removed unneeded includes of base/scoped_ptr.h. Reduce usage from ~800 files ↵thestig@chromium.org2009-03-131-1/+0
| | | | | | | | to ~400. Review URL: http://codereview.chromium.org/46039 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11651 0039d316-1c4b-4281-b951-d872f2087c98
* Checkin files I missed.jam@chromium.org2009-03-131-1/+0
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11602 0039d316-1c4b-4281-b951-d872f2087c98
* Bring back overriding setParentVisible, since it's needed when a page ↵jam@chromium.org2009-03-121-0/+1
| | | | | | | | | scripts the parent element to make it invisible/visible. BUG=8657 Review URL: http://codereview.chromium.org/45005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11508 0039d316-1c4b-4281-b951-d872f2087c98
* WebKit merge 40474:40500 [chromium-side].ericroman@google.com2009-02-041-5/+5
| | | | | | Review URL: http://codereview.chromium.org/21029 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9121 0039d316-1c4b-4281-b951-d872f2087c98
* POSIX: gfx::NativeViewId and CrossProcessEventagl@chromium.org2009-01-271-2/+3
| | | | | | | | | | | | | | | | | | | 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
* No functional change. Delete trailing whitespace and word-wrap to 80 columns.evan@chromium.org2009-01-241-3/+5
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8609 0039d316-1c4b-4281-b951-d872f2087c98
* Relands 8521, it isn't the culprit. Sorry John.sky@google.com2009-01-231-1/+0
| | | | | | | | | BUG=none TEST=none TBR=jam Review URL: http://codereview.chromium.org/18706 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8547 0039d316-1c4b-4281-b951-d872f2087c98
* Backs out r8521 in hopes of greener trees.sky@google.com2009-01-231-0/+1
| | | | | | | | | BUG=none TEST=none TBR=jam Review URL: http://codereview.chromium.org/18545 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8546 0039d316-1c4b-4281-b951-d872f2087c98
* Fix reloading a page with a pdf not working. The problem was that we were ↵jam@chromium.org2009-01-221-1/+0
| | | | | | | | sending an invalid window to DeferWindowPos (the previous window as it's going away). But we didn't really need to override setParentVisible since overriding setParent is enough. Review URL: http://codereview.chromium.org/18519 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8521 0039d316-1c4b-4281-b951-d872f2087c98
* Improve scrolling performance when there are many windowed plugins in a page.jam@chromium.org2009-01-161-4/+2
| | | | | | | | 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
* Handle HTTP 200 responses received in response to byte range requests issued ↵ananta@chromium.org2008-12-171-2/+27
| | | | | | | | by the plugin. This means that the server does not support byte range requests. Firefox handles this by destroying the current plugin instance and creating a new instance to handle the response. The stream which is created to pass the data off to the plugin is not seekable.Fix is to emulate Firefox behavior. Will work on unit testing the NPN_RequestRead related code in a separate CB. This fixes http://code.google.com/p/chromium/issues/detail?id=5403Bug=5403 Review URL: http://codereview.chromium.org/14122 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7139 0039d316-1c4b-4281-b951-d872f2087c98
* WebKit Merge 39143:39309, Part 8 (port side)dglazkov@google.com2008-12-161-1/+1
| | | | | | Review URL: http://codereview.chromium.org/14140 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7040 0039d316-1c4b-4281-b951-d872f2087c98
* Improve PDF FastWebView performance. This occurs because the manual data ↵ananta@chromium.org2008-12-061-0/+6
| | | | | | | | | | | | | | | | stream load does not get cancelled correctly. This causes the IPC messages for the manual data stream to continue going back and forth. They are ignored by the plugin anyways. This fixes http://code.google.com/p/chromium/issues/detail?id=5196. Fix is to cancel the manual document load correctly. Bug=5196 Review URL: http://codereview.chromium.org/13198 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6486 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting r6396 the PDF fix to not cancel the manual data streamananta@chromium.org2008-12-051-0/+2
| | | | | | | | | | | | load when the plugin calls NPN_RequestRead. I was looking at the wrong stream implementation in Firefox :( Bug=5009 TBR=jam Review URL: http://codereview.chromium.org/13212 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6454 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
* Relanding this fix. The earlier attempt broke test_shell_tests. The fixananta@chromium.org2008-11-211-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | has been added to this CB. Fix Silverlight windowless plugin painting issues. This fixes the following issues:- 1. http://code.google.com/p/chromium/issues/detail?id=4272 2. http://code.google.com/p/chromium/issues/detail?id=301 (Partially) The fixes are as below:- 1. Silverlight in the NPP_HandleEvent call for WM_PAINT, calls NPN_GetProperty for a bunch of properties like pageXOffset, pageYOffset, etc. It expects these properties to have integer types on return. We always return double. Firefox returns integer for these properties. Added a check in the conversion to NPVariant function in v8 to check for whether the value is an integer and return the intger type. 2. When the windowless plugin calls NPN_InvalidateRect we ask the plugin to paint in the same call, which the Silverlight plugin does not like. It relies on the fact that browsers would initiate invalidation asynchronously and eventually paint. This is a perfectly legal assumption. The Flash plugin does work if we synchronously ask it to paint. However other plugins could have similar issues. I verified with worldofwarcraft.com to see if the async paint has any sideeffects and there were none. 3.If the Silverlight plugin is not visible initially as on msdn.microsoft.com, it does not paint. This occurs because the plugin expects proper paints to come from the browser. It does not invalidate itself in UpdateGeometry as Flash. The plugin widget on msdn is not dynamic. It does call NPN_InvalidateRect initially when it is not visible. We don't send the call to the renderer as the plugin is not visible. To workaround this we now track the damaged rect even if the rect does not intersect the clipping rect of the plugin. In a geometry update if the plugin is visible, we send over the accumulated damaged rect to the renderer. The Silverlight plugin instance on msdn.microsoft.com does not work correctly even with these fixes. However it paints correctly. R=jam Bug=4272,301 Review URL: http://codereview.chromium.org/11569 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@5829 0039d316-1c4b-4281-b951-d872f2087c98
* Revert r5816 due to InvokeMethods failures in test_shell_tests.sgk@google.com2008-11-211-2/+1
| | | | | | Review URL: http://codereview.chromium.org/11342 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@5818 0039d316-1c4b-4281-b951-d872f2087c98
* Fix Silverlight windowless plugin painting issues. This fixes theananta@chromium.org2008-11-211-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | following issues:- 1. http://code.google.com/p/chromium/issues/detail?id=4272 2. http://code.google.com/p/chromium/issues/detail?id=301 (Partially) The fixes are as below:- 1. Silverlight in the NPP_HandleEvent call for WM_PAINT, calls NPN_GetProperty for a bunch of properties like pageXOffset, pageYOffset, etc. It expects these properties to have integer types on return. We always return double. Firefox returns integer for these properties. Added a check in the conversion to NPVariant function in v8 to check for whether the value is an integer and return the intger type. 2. When the windowless plugin calls NPN_InvalidateRect we ask the plugin to paint in the same call, which the Silverlight plugin does not like. It relies on the fact that browsers would initiate invalidation asynchronously and eventually paint. This is a perfectly legal assumption. The Flash plugin does work if we synchronously ask it to paint. However other plugins could have similar issues. I verified with worldofwarcraft.com to see if the async paint has any sideeffects and there were none. 3.If the Silverlight plugin is not visible initially as on msdn.microsoft.com, it does not paint. This occurs because the plugin expects proper paints to come from the browser. It does not invalidate itself in UpdateGeometry as Flash. The plugin widget on msdn is not dynamic. It does call NPN_InvalidateRect initially when it is not visible. We don't send the call to the renderer as the plugin is not visible. To workaround this we now track the damaged rect even if the rect does not intersect the clipping rect of the plugin. In a geometry update if the plugin is visible, we send over the accumulated damaged rect to the renderer. The Silverlight plugin instance on msdn.microsoft.com does not work correctly even with these fixes. However it paints correctly. R=jam Bug=4272,301 Review URL: http://codereview.chromium.org/11492 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@5816 0039d316-1c4b-4281-b951-d872f2087c98
* This fixes bug http://code.google.com/p/chromium/issues/detail?id=3881, whichananta@chromium.org2008-10-311-2/+2
| | | | | | | | | | | | | | was NPAPI plugin UI test failures. This occured as a sideeffect of the webkit merge. Some functions in widget.h which were implemented by WebPluginContainer no longer exist. We need to implement their replacements on similar lines. Bug=3881 R=jam Review URL: http://codereview.chromium.org/8775 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@4343 0039d316-1c4b-4281-b951-d872f2087c98
* Landing 36102:37604 merge on trunkdglazkov@google.com2008-10-301-6/+6
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@4222 0039d316-1c4b-4281-b951-d872f2087c98
* This fixes http://code.google.com/p/chromium/issues/detail?id=3585, which is ↵ananta@chromium.org2008-10-231-3/+17
| | | | | | | | | | an issue with videos on sites like thedailyshow.com not showing up in Chrome. We recently made a change to send out the plugin SRC as the referrer in requests initiated by plugins.We also use the GetURLNotify codepath for requests which are initiated by us when the plugin is instantiated. It looks like the other browsers don't do the same, and only use the SRC as the referer for explicit plugin requests.Based on a reply on the PluginFutures list we emulate this behavior, which is to default to the containing frame URL as the referer for requests not initiated by plugins. R=jam Review URL: http://codereview.chromium.org/7871 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@3862 0039d316-1c4b-4281-b951-d872f2087c98
* Plugin changes to make JSC build work.ojan@google.com2008-10-221-0/+4
| | | | | | Review URL: http://codereview.chromium.org/7883 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@3783 0039d316-1c4b-4281-b951-d872f2087c98
* - Remove whitespace at the end of the lineagl@chromium.org2008-10-211-8/+8
| | | | | | | | | | | | | - A few spelling mistakes in the comments - Fix the order of initilization in the class (gcc warning) - use the string utility to convert between string type (gcc warning) - Ifdef the keyboard/mouse/painting which is currently only implemented on Windows Review URL: http://codereview.chromium.org/7827 Patch from Torchmobile Inc.. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@3690 0039d316-1c4b-4281-b951-d872f2087c98
* * Revert "- Remove whitespace at the end of the line"agl@chromium.org2008-10-211-8/+8
| | | | | | | | | This reverts commit r3676. Review URL: http://codereview.chromium.org/8025 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@3678 0039d316-1c4b-4281-b951-d872f2087c98
* - Remove whitespace at the end of the lineagl@chromium.org2008-10-211-8/+8
| | | | | | | | | | | | | - A few spelling mistakes in the comments - Fix the order of initilization in the class (gcc warning) - use the string utility to convert between string type (gcc warning) - Ifdef the keyboard/mouse/painting which is currently only implemented on Windows Review URL: http://codereview.chromium.org/7827 Patch from Torchmobile Inc.. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@3676 0039d316-1c4b-4281-b951-d872f2087c98
* Fix perf regression with iframe shim.pkasting@chromium.org2008-10-201-2/+6
| | | | | | | | See http://codereview.chromium.org/7654 Patch by tulrich@google.com, reviewed by pkasting git-svn-id: svn://svn.chromium.org/chrome/trunk/src@3609 0039d316-1c4b-4281-b951-d872f2087c98
* Replace MSVC pragmas with the macro. Also adds two filestc@google.com2008-10-161-3/+4
| | | | | | | | | | | | from webkit/glue to the build rule. Patch from icefox (TorchMobile) http://codereview.chromium.org/7418 Review URL: http://codereview.chromium.org/7454 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@3490 0039d316-1c4b-4281-b951-d872f2087c98
* Patch by Thatcher Ulrich <tulrich@google.com>.ojan@google.com2008-10-091-1/+17
| | | | | | | | | | | | | | | 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
* Merge the chrome_webkit_merge_branch back on to trunk. This brings ustc@google.com2008-10-011-7/+5
| | | | | | | up to webkit@36102. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2778 0039d316-1c4b-4281-b951-d872f2087c98
* This fixes the following bugs:-iyengar@google.com2008-09-241-1/+4
| | | | | | | | | | | | | | | | | | | 1. http://code.google.com/p/chromium/issues/detail?id=1473 2. http://code.google.com/p/chromium/issues/detail?id=1533 Our plugin implementation currently sends the containing frame URL as the default referer in HTTP requests initiated by plugins. Based on a discussion on the Plugin futures mailing list, an agreement has been reached to mimic IE behavior and send in the plugin source URL as the default referer in plugin requests. If the plugin is instantiated with an empty SRC, then use the containing frame URL as the referer. Bug=1473,1533 R=jam Review URL: http://codereview.chromium.org/3180 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2539 0039d316-1c4b-4281-b951-d872f2087c98
* This CB fixes the following issue1. ↵iyengar@google.com2008-09-191-1/+21
| | | | | | | | http://code.google.com/p/chromium/issues/detail?id=206This is a performance issue while loading PDF documents. The fix is to support PDF fast webview, which is basically support for the NPN_RequestRead API, which allows a plugin to request specific byte ranges in HTTP GET requests. This also needs support for seekable streams. Our support for seekable streams is limited to HTTP servers which allow byte range requests. Firefox also supports a mode in which the the browser caches the file on disk for servers which don't support byte range requests. The plugin_data_stream.cc/.h files are being removed as there is not much value in their existence. The needed functionality is available in the PluginStreamUrl class, which now services manual data streams as well. Testing this is a touch tricky as we need a HTTP server which serves byte range requests. Will add those in a subsequent CB.Also fixed a bug in the multipart parser where we need to ignore leading newline characters while parsing the header.Bug=206 Review URL: http://codereview.chromium.org/2896 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2400 0039d316-1c4b-4281-b951-d872f2087c98
* This fixes http://code.google.com/p/chromium/issues/detail?id=643, whichiyengar@google.com2008-09-101-0/+11
| | | | | | | | | | | | | | | | | | | is an issue with the shockwave game not loading. The plugin issues a number of geturlnotify requests. Some of these requests come in with response headers without the content length. We would pass in -1 in the NPStream passed down to the plugin. As the end field in the NPStream structure is an unsigned integer, the plugin would expect more data to arrive and hence the issue. The fix is to emulate Safari behavior and set the end field to 0 if the length is -1. Bug=643 Review URL: http://codereview.chromium.org/1676 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1958 0039d316-1c4b-4281-b951-d872f2087c98
* Fix webkit.xcodeproj. Make it use our new xcconfig and common build directorymmentovai@google.com2008-09-061-0/+1
| | | | | | | setup. Turn off headermaps and use explicit #include paths everywhere. Review URL: http://codereview.chromium.org/269 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1815 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
* Step 1 at making Gears run in the renderer process (enabled by switchmpcomplete@google.com2008-08-151-0/+1
| | | | | | | | | "--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
* Add webkit to the repository.initial.commit2008-07-271-0/+282
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-02-01 11:21:40 +0000