summaryrefslogtreecommitdiffstats
path: root/chrome/plugin
Commit message (Collapse)AuthorAgeFilesLines
* Updating so that Gears can spawn file selectors when running in the renderer ↵zork@google.com2009-01-131-0/+13
| | | | | | | | process Review URL: http://codereview.chromium.org/14907 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7986 0039d316-1c4b-4281-b951-d872f2087c98
* remove chrome dependencies from win sandboxing headers. Wrap sandbox code topinkerton@google.com2009-01-091-2/+6
| | | | | | | make the main routine a little cleaner. Unify the parameters of each of the "main" entry points so we can more easily abstract platform differences in the future. BUG=5323 Review URL: http://codereview.chromium.org/17426 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7825 0039d316-1c4b-4281-b951-d872f2087c98
* Change "dll" to "plugin" where appropriate.avi@google.com2009-01-063-5/+5
| | | | | | Review URL: http://codereview.chromium.org/16543 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7617 0039d316-1c4b-4281-b951-d872f2087c98
* Move plugins to FilePaths, some cleanupavi@google.com2009-01-065-12/+14
| | | | | | Review URL: http://codereview.chromium.org/16456 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7588 0039d316-1c4b-4281-b951-d872f2087c98
* Mass convert ChromeStaticLibrary -> ChromeLibrary, including pulling the ↵evanm@google.com2008-12-261-1/+1
| | | | | | | | | | | updated ICU dep that uses it as well. Add a SHARED scons command-line flag to build shared libraries. Review URL: http://codereview.chromium.org/16477 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7479 0039d316-1c4b-4281-b951-d872f2087c98
* Fixes NPAPITester ui tests. I was trying to diagnose failing ui testssky@google.com2008-12-231-3/+29
| | | | | | | | | | | | | | and with page heap enabled these tests consistenly crashed on me. I've no idea about this code, but this change fixed it. As far as I can tell in some cases Send deletes the NPObjectProxy, so that any code that attempts to access the proxy after the Send may crash. BUG=none TEST=none Review URL: http://codereview.chromium.org/16418 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7452 0039d316-1c4b-4281-b951-d872f2087c98
* Initial generation of native Visual Studio solution filessgk@google.com2008-12-191-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (project files still to come). To wit: * Solution file configuration is in *_sln.scons files (base\base_sln.scons, chrome\chrome_sln.scons). * Individual Project file configuration is in the the .scons file for the relevant target (base\base_unittests.scons, third_party\libxml\libxml.scons, etc.)--that is, where their file lists will live. * MSVSProject() calls are currently placeholders that establish the existence of Project Nodes (and Project dependencies) but don't yet have actual Project configuration information (file lists, .vsprops, etc.). * Configuraiton is very manual. In particular, the entries in the .sln file will be written out in exactly the order specified in the configuration(s). The current ordering is taken from our existing .sln files, so we can generate virtually the same configurations on output. * Generated solution files are nearly byte-for-byte identical with our existing .sln files, modulo: * net\dump_cache has a WebsiteProperties sections (making that configurable per project isn't important right now); * sandbox\sandbox.sln was missing a dependency of base.vcproj on on debug_message.vcproj (present in other .sln files) * webkit\webkit.sln was missing dependencies of WebCore.vcproj on libxml_config.vcproj and libxslt_config.vcproj (present in chrome.sln); * add a handful of other miscellaneous missing dependencies on various .vcproj definitions in chrome.sln (present in other .sln files). * remove stats_viewer.csproj from chrome.sln (sorry, mbelshe), which was complicating the solution configuration with unnecessary (for us) "Mixed Platform" types; * All MSVSFolder(), MSVSProject() and MSVSSolution() calls have hard-wired guid= values taken from our existing configuration, so we can: 1) verify generation of working configs; 2) minimize diffs when checking in generated .sln files. We can remove these in the future in favor of extracting them from existing .sln files if we wish. * Add ChromeMSVSFolder(), ChromeMSVSProject() and ChromeMSVSSolution() wrappers to chromium_builders.py, that gate the underlying call to the env.MSVS*() builders based on whether env.Bit('msvs') is set (i.e., we're in --mode=msvs). * Remove platform-specific gating of to-be-ported .scons files that we now need to load on any platform to generate coheren MSVS files. Move the env.Bit('windows') tests for actually building their executables into the individual .scons files. Review URL: http://codereview.chromium.org/14472 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7297 0039d316-1c4b-4281-b951-d872f2087c98
* Convert from using env['PLATFORM'] directly to using the more flexiblesgk@google.com2008-12-181-2/+2
| | | | | | | | | | | | | | | | | | and better-thought-out Hammer env.Bits() idioms: * env['PLATFORM'] == 'win32' => env.Bit('windows') * env['PLATFORM'] == 'posix' => env.Bit('linux') * env['PLATFORM'] == 'darwin' => env.Bit('mac') New idioms: * env.Bit('posix') => really does mean "any POSIX platform" * env.AnyBits('mac', 'linux') => specifically mac or linux, excluding other POSIX platforms Where we were using compound conditionals (e.g., "env['PLATFORM'] in ('posix', 'darwin')") I tried to take my best shot at translating the intent (i.e., "env.Bits('posix')" for something POSIX, "not env.Bits('mac')" for something not yet ported to Mac, etc.) Review URL: http://codereview.chromium.org/15051 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7270 0039d316-1c4b-4281-b951-d872f2087c98
* Move the "platform" wrappers in skia/ext to the skia namespace.brettw@google.com2008-12-172-2/+2
| | | | | | Review URL: http://codereview.chromium.org/14110 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7182 0039d316-1c4b-4281-b951-d872f2087c98
* Handle HTTP 200 responses received in response to byte range requests issued ↵ananta@chromium.org2008-12-171-0/+1
| | | | | | | | 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
* Switch back svn:eol-style=native for .sln, .vcproj and .vsprops files.maruel@chromium.org2008-12-161-231/+231
| | | | | | | Patch fails otherwise on non-Windows platforms. Review URL: http://codereview.chromium.org/14478 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7093 0039d316-1c4b-4281-b951-d872f2087c98
* Platform cleanup in common/ and even porting few files and unit tests.phajdan.jr@chromium.org2008-12-151-0/+6
| | | | | | Review URL: http://codereview.chromium.org/14420 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6982 0039d316-1c4b-4281-b951-d872f2087c98
* A new shot at the old system monitor changelist.mbelshe@google.com2008-12-131-0/+4
| | | | | | Review URL: http://codereview.chromium.org/12883 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6974 0039d316-1c4b-4281-b951-d872f2087c98
* Untested fix for build failures.pkasting@chromium.org2008-12-101-0/+2
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6752 0039d316-1c4b-4281-b951-d872f2087c98
* Fixing build bustage. Adding files which were part of the original changeananta@chromium.org2008-12-052-0/+6
| | | | | | | | | | 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-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
generated by cgit v1.1 at 2025-01-18 22:58:11 +0000