summaryrefslogtreecommitdiffstats
path: root/chrome/plugin
Commit message (Collapse)AuthorAgeFilesLines
* Don't cancel the original manual data stream request when the plugin invokesananta@chromium.org2008-12-042-6/+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
* Changed svn:eol-style of all .sln and .vcproj files to CRLFscherkus@chromium.org2008-12-041-231/+231
| | | | | | Review URL: http://codereview.chromium.org/13133 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6372 0039d316-1c4b-4281-b951-d872f2087c98
* Rollbackmbelshe@google.com2008-12-011-4/+0
| | | | | | Review URL: http://codereview.chromium.org/13009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6127 0039d316-1c4b-4281-b951-d872f2087c98
* A new copy of the old system monitor changelist.mbelshe@google.com2008-11-301-0/+4
| | | | | | Review URL: http://codereview.chromium.org/12817 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6126 0039d316-1c4b-4281-b951-d872f2087c98
* Add a NULL channel check in CreateNPVariantParam as it can be called withananta@chromium.org2008-11-241-9/+15
| | | | | | | | | | | | | a NULL channel during renderer plugin shutdown. Fixes bug http://code.google.com/p/chromium/issues/detail?id=4740 R=jam Bug=4740 Review URL: http://codereview.chromium.org/12609 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@5943 0039d316-1c4b-4281-b951-d872f2087c98
* Remove base versions of the graphics headers, which previously just ↵brettw@google.com2008-11-222-2/+2
| | | | | | | | forwarded to the skia ones. Review URL: http://codereview.chromium.org/11588 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@5894 0039d316-1c4b-4281-b951-d872f2087c98
* Relanding this fix. The earlier attempt broke test_shell_tests. The fixananta@chromium.org2008-11-212-6/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-212-27/+6
| | | | | | 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-212-6/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix a potential race with cookie requests between renderer and gears.mpcomplete@google.com2008-11-171-2/+18
| | | | | | | BUG=1487502 Review URL: http://codereview.chromium.org/10960 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@5565 0039d316-1c4b-4281-b951-d872f2087c98
* Add Terminate() to the Process object, have RenderProcessHost use this to ↵brettw@google.com2008-11-144-20/+21
| | | | | | | | | | 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
* Re-do the way browser windows are shown:ben@chromium.org2008-11-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | - Remove the path from WinMain to the Browser object passing the show_command. For the Browser object, this is a problem since this value isn't portable. For the code in general it involves a lot of ugly wiring. It's completely unnecessary since the value is obtainable via GetStartupInfo. - Remove show_command plumbing from all over the place (session restore, web app launcher, etc) Change the way browser windows are constructed: - The browser constructor now takes just a type and a profile, and simply initializes the object. - Some configuration that used to be part of the constructor that was only used in one or two use cases (initial bounds, maximized state, web app name) are split into separate setters. - Window creation is split out into a separate step to be called post configuration. - Assorted static helper functions added to Browser to make construction of common types easy. - Remove Browser::Show in favor of BrowserWindow::Show - Adjust all callers to use the new helpers. Change the way ChromeViews restores window placement: - Split restored size determination from restored maximized determination. They are needed by the code at different times. Size restoration happens when the window is constructed and Window::SetInitialBounds is called. Maximized state restoration happens when the window is shown for the first time and SW_SHOWMAXIMIZED or SW_SHOWNORMAL is needed. Thus, replace WindowDelegate::RestoreWindowPosition with WindowDelegate::RestoreWindowBounds and WindowDelegate::RestoreMaximizedState. - Window::SetInitialBounds calls WindowDelegate::RestoreWindowBounds - Window::Show calls WindowDelegate::RestoreMaximizedState - Adjusts all WindowDelegate implementations that override RestoreWindowPosition to implement these new methods instead. - Move "playback/record" mode window size setting from browser_init to Browser::RestoreWindowBounds. - Provide a virtual function on Window called GetShowState that determines the default show state to be used when Window::Show is called. For most windows and dialogs this is SW_SHOWNORMAL. AeroGlassFrame/OpaqueFrame (the browser window frames) override this since they're the app's main windows to return the value provided by GetStartupInfo which gives the value from the app shortcut. http://crbug.com/3557 Review URL: http://codereview.chromium.org/10896 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@5417 0039d316-1c4b-4281-b951-d872f2087c98
* Fix http://code.google.com/p/chromium/issues/detail?id=4270. Test case added.mpcomplete@google.com2008-11-121-1/+1
| | | | | | | | BUG=4270 Review URL: http://codereview.chromium.org/10620 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@5310 0039d316-1c4b-4281-b951-d872f2087c98
* NO CODE CHANGE. Just force a build.maruel@chromium.org2008-11-111-4/+3
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@5171 0039d316-1c4b-4281-b951-d872f2087c98
* No code change. Force a build.maruel@chromium.org2008-11-071-5/+6
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@4986 0039d316-1c4b-4281-b951-d872f2087c98
* Convert chrome/plugin to the new naming (SConscript => plugin.scons).sgk@google.com2008-11-031-12/+25
| | | | | | Review URL: http://codereview.chromium.org/9049 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@4470 0039d316-1c4b-4281-b951-d872f2087c98
* NO CODE CHANGE. Just force a build to see how badly broken is the tree.maruel@chromium.org2008-10-311-4/+3
| | | | | | | Hint, don't ever sync to this revision. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@4279 0039d316-1c4b-4281-b951-d872f2087c98
* No code change. Just to force a build.maruel@chromium.org2008-10-281-4/+3
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@4075 0039d316-1c4b-4281-b951-d872f2087c98
* No code change. Just to force a rebuild.maruel@chromium.org2008-10-281-4/+3
| | | | | | Review URL: http://codereview.chromium.org/8667 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@4074 0039d316-1c4b-4281-b951-d872f2087c98
* No code change. Just force a build.maruel@google.com2008-10-281-4/+3
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@4064 0039d316-1c4b-4281-b951-d872f2087c98
* Superficial change to force a build.maruel@chromium.org2008-10-271-4/+3
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@3994 0039d316-1c4b-4281-b951-d872f2087c98
* This is a patch for bug 1385045: Adobe Acrobat 9.0 crash.nsylvain@chromium.org2008-10-221-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adobe Acrobat 9.0 loads a dll called bib.dll. Usually it unloads it 30 seconds after the last instance of the plugin goes away, or when the browser process goes away. To know if the browser process goes away, it subclasses the main browser window. It seems to work fine in firefox, but it does not work in chrome. Also the 30 seconds delay does not work because we close the plugin process too fast (10 seconds) after the last instance of the plugin is closed. bib.dll is then unloaded by ExitProcess, which causes a crash in bib.dll. We could wait ~35 seconds after the last instance before closing the process, but it might be problematic with upgrades and could result in plugin process outliving the brower process. This current patch just kills the process before ExitProcess, so it does not cause a crash and display an error message to the user. This is not a fix, this is just a usuability improvement. As far as I know we are still waiting for help from the Adobe team on this issue. They would need to find a way to unload bib.dll cleanly in chrome. BUG: 1385045 Review URL: http://codereview.chromium.org/8015 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@3753 0039d316-1c4b-4281-b951-d872f2087c98
* Using $CHROME_SRC_DIR in place of hash/..bradnelson@google.com2008-10-221-1/+1
| | | | | | | | This will facilitate changing where the main sconstruct lives. Review URL: http://codereview.chromium.org/7847 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@3725 0039d316-1c4b-4281-b951-d872f2087c98
* Patch by Thatcher Ulrich <tulrich@google.com>.ojan@google.com2008-10-094-4/+10
| | | | | | | | | | | | | | | 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
* Fix videos stopping playing. Only send an invalidate to the renderer if ↵jam@chromium.org2008-10-091-2/+4
| | | | | | | | | it's within the clipping region, otherwise we'll wait forever for a did paint message that doesn't come. BUG=115 Review URL: http://codereview.chromium.org/6257 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@3123 0039d316-1c4b-4281-b951-d872f2087c98
* Attempt 2 at landing this patch. It broke the Mac/linux builds. Fix for now isananta@chromium.org2008-10-093-2/+15
| | | | | | | | | | | | | | | | | | | | | | 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-093-15/+2
| | | | | | 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-083-2/+15
| | | | | | | | | | | | | | | | | | 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
* Bring chrome/plugin/SConscript into the Linux build.mmoss@google.com2008-10-011-14/+22
| | | | | | | | BUG=3033 Review URL: http://codereview.chromium.org/6044 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2771 0039d316-1c4b-4281-b951-d872f2087c98
* Fix painting problem with transparent plugins because plugins were ignoring ↵jam@chromium.org2008-10-014-64/+113
| | | | | | | | | | | | | | | 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
* This CL adds new UI tests for the SSL UI.jcampan@chromium.org2008-09-241-1/+2
| | | | | | | | | | | | | | | | | | | | Some more info: SSL UI Tests: Added new tests for redirects and frames. Also improved the mixed-content test to exercise the "block mixed-contents" preference and the show info-bar. Automation: For the new UI tests, added methods to tab_proxy and browser_proxy. The ones of most interest are GetLastNavigatinTime and WaitForNavigation that ensures we wait for a navigation to occur or have occured when taking actions that asynchronously trigger navigations. Resource loading: Added a flag to the response we get when loading a resource that indicates whether that resource was filtered (blocked or altered) by the security peer. We use this flag to notify back the browser when we report a load has been committed. This is so the SSL manager knows a frame has been filtered (in which case we have no cert info but should not consider that as unsafe). BUG=2004 Review URL: http://codereview.chromium.org/3165 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2553 0039d316-1c4b-4281-b951-d872f2087c98
* Desynchronize windowless plugin painting. This greatly improves the paintingjam@chromium.org2008-09-224-167/+166
| | | | | | | | 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
* This fixes the following bugs:-iyengar@google.com2008-09-201-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1.http://code.google.com/p/chromium/issues/detail?id=292 This was a painting issue in the XStandard plugin. The bug occurs in a windowed instance of the plugin. We handle window repositions in the plugin process until the window becomes visible. We set the SWP_NOREDRAW flag in the SetWindowPos call. This turns off client/non-client paints. After the SetWindowPos call we invalidate the client area. The plugin only receives WM_PAINT as a result. The plugin relies on the WM_NCPAINT message being received as well. In any case the SWP_NOREDRAW flag does not buy us much as we invalidate immediately after. The fix is to take out this flag. 2.http://code.google.com/p/chromium/issues/detail?id=2556 The plugin invoked the NPN_GetValue function to retreive the window script object. This call fails in this case probably because the plugin instance in the renderer process is in the process of shutting down. We return a failure from the call. The plugin fails to check the return code and ends up invoking NPN_GetProperty on a NULL NPObject which causes a crash in chrome when we try to create a proxy for the same. The fix is to add NULL NPObject checks in the NPObjectProxy members and return early. Bug=292,2556 R=jam Review URL: http://codereview.chromium.org/3176 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2429 0039d316-1c4b-4281-b951-d872f2087c98
* Adding a CPAPI function to make a function call asynchonously on the plugin ↵zork@google.com2008-09-191-0/+13
| | | | | | | | thread. Review URL: http://codereview.chromium.org/2969 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2414 0039d316-1c4b-4281-b951-d872f2087c98
* This CB fixes the following issue1. ↵iyengar@google.com2008-09-194-4/+29
| | | | | | | | 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
* Adding sync plugin messages, and plugin broadcasts to the renderer processeszork@google.com2008-09-151-0/+24
| | | | | | Review URL: http://codereview.chromium.org/2411 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2246 0039d316-1c4b-4281-b951-d872f2087c98
* Replace all instances of <hash_map> with a "base/hash_tabe.h",erg@google.com2008-09-083-10/+6
| | | | | | | | | | | which does the right thing based on whatever platform we're compiling for, along with changing the hardcoded "stdext::", which is a MSVC++ism to use base::hash_{map,set}. B=1869 Review URL: http://codereview.chromium.org/1629 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1862 0039d316-1c4b-4281-b951-d872f2087c98
* Fix a crashing bug when shutting down the plugin process.michaeln@google.com2008-09-051-1/+1
| | | | | | Review URL: http://codereview.chromium.org/459 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1747 0039d316-1c4b-4281-b951-d872f2087c98
* Update Copyright text in SCons config files.sgk@google.com2008-09-011-28/+4
| | | | | | TBR: beng git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1607 0039d316-1c4b-4281-b951-d872f2087c98
* Some more changes so that Chromium and Google Chrome do not clash with each ↵rahulk@google.com2008-08-311-1/+2
| | | | | | | | | other while running at the same time. BUG=1296800 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1600 0039d316-1c4b-4281-b951-d872f2087c98
* Chrome changes corresponding to my message_loop_type CL.darin@google.com2008-08-263-2/+9
| | | | 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-2421-589/+84
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1287 0039d316-1c4b-4281-b951-d872f2087c98
* Port the Thread class properly to Mac and Linux. This involved portingdarin@google.com2008-08-211-1/+1
| | | | | | | | | | | | PlatformThread and creating an API on PlatformThread to create a native thread and later join with it. I also made a few other tweaks to PlatformThread, such as eliminating the Current() method which appears to be unused. The operator==() is also unused, so I killed it as well. I made a few other miscellaneous cleanups and adjustments. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1146 0039d316-1c4b-4281-b951-d872f2087c98
* Step 1 at making Gears run in the renderer process (enabled by switchmpcomplete@google.com2008-08-151-0/+3
| | | | | | | | | "--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
* git-svn-id: svn://svn.chromium.org/chrome/trunk/src@873 ↵awalker@google.com2008-08-141-4/+4
| | | | 0039d316-1c4b-4281-b951-d872f2087c98
* Set the svn:eol-style to LF on all SConscript filestc@google.com2008-08-131-63/+63
| | | | | | TBR=evanm git-svn-id: svn://svn.chromium.org/chrome/trunk/src@823 0039d316-1c4b-4281-b951-d872f2087c98
* Fix race condition in pluginjabdelmalek@google.com2008-08-131-0/+3
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@767 0039d316-1c4b-4281-b951-d872f2087c98
* Enabling sync_channel in the browser to allow accessibility code making ↵jcampan@google.com2008-08-122-3/+6
| | | | | | | | | 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
* Fix a bunch of include problems that my deps checker tool found. Mostly I ↵brettw@google.com2008-08-084-6/+6
| | | | | | made the names of some third party includes fully qualified. I removed a qualification on a couple of the WebKit port includes that confuses it and isn't necessary (since WebKit includes aren't fully qualified). git-svn-id: svn://svn.chromium.org/chrome/trunk/src@604 0039d316-1c4b-4281-b951-d872f2087c98
* Move away from the deprecated atomic.h interface to AtomicRefCount and ↵deanm@google.com2008-08-071-1/+1
| | | | | | AtomicSequenceNumber. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@510 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-01-19 18:03:22 +0000