summaryrefslogtreecommitdiffstats
path: root/chrome/plugin
Commit message (Collapse)AuthorAgeFilesLines
* Reverting 10080.jam@chromium.org2009-02-209-97/+218
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10082 0039d316-1c4b-4281-b951-d872f2087c98
* Refactor code from RenderThread and PluginThread and move it to ChildThread. ↵jam@chromium.org2009-02-209-218/+97
| | | | | | | | | ChildProcess now owns the ChildThread, which removes duplicate code and simplifies things. Clean up ChildProcess, there really was no need for all the templates and statics in it and its subclasses. Review URL: http://codereview.chromium.org/21502 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10080 0039d316-1c4b-4281-b951-d872f2087c98
* Reduce the amount of included header files. Vast change like in "Oh God! ↵maruel@chromium.org2009-02-182-0/+9
| | | | | | | | This revision changes half of the source files!". Review URL: http://codereview.chromium.org/20378 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9958 0039d316-1c4b-4281-b951-d872f2087c98
* Get something in chrome/plugin/ compiling to make Scons happy.thestig@chromium.org2009-02-182-2/+5
| | | | | | Review URL: http://codereview.chromium.org/20449 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9934 0039d316-1c4b-4281-b951-d872f2087c98
* Lots of small nits to help to split off webkit.dll.maruel@chromium.org2009-02-124-23/+24
| | | | | | | | | - Stop directly referencing WebPluginDelegateImpl. - Make the password manager to not allocation the data on heap. - Remove some unneeded includes. Review URL: http://codereview.chromium.org/20208 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9692 0039d316-1c4b-4281-b951-d872f2087c98
* Cleanup some forward declared structs that are not being used.thestig@chromium.org2009-02-051-1/+0
| | | | | | | Also do some lint removal while I'm at it. Review URL: http://codereview.chromium.org/20107 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9269 0039d316-1c4b-4281-b951-d872f2087c98
* Fix the dependency checker tool. Rules for a directory did modify their ↵stoyan@chromium.org2009-02-051-0/+9
| | | | | | | | | | directory parent rules. Using copy.copy() solves the problem.Additional fix when "allow-current-directory" rules was not applied if DEPS file is missing. Updated few DEPS file with reasonable rules. To prevent tree closing other dependencies are added. These need to be either legitimated or dependency removed. Review URL: http://codereview.chromium.org/21025 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9221 0039d316-1c4b-4281-b951-d872f2087c98
* Finish taking out render_messages.h includes from headers.jam@chromium.org2009-02-053-0/+3
| | | | | | Review URL: http://codereview.chromium.org/20072 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9209 0039d316-1c4b-4281-b951-d872f2087c98
* Commiting the changes from my previous cl that are specific to not including ↵jam@chromium.org2009-02-042-1/+4
| | | | | | | | | | render_messages.h/plugin_message.h unless necessary. TBR=mpcomplete Review URL: http://codereview.chromium.org/20059 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9189 0039d316-1c4b-4281-b951-d872f2087c98
* Revert my change to get the tree green. Not sure why the tests became ↵jam@chromium.org2009-02-042-4/+1
| | | | | | | | | | flaky. I'll try to check them in again but in smaller chunks tomorrow. TBR=mpcomplete Review URL: http://codereview.chromium.org/21039 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9132 0039d316-1c4b-4281-b951-d872f2087c98
* Make it easier/less work/less error-prone to create new IPC channel types ↵jam@chromium.org2009-02-042-1/+4
| | | | | | | | (i.e. renderer/plugin).Instead of having each message file include the internal one several times with different ifdefs, move that logic to ipc_message_macros.h. Also make the message class starting IDs come from an enum to ensure we don't use a value twice. I simplified the logging code a bit so we don't need X_messages.cc files.Clean up places that we were doing manual packing/unpacking. Most of this was in the automation code. I added a few new template functions to make it convenient to read the parameters from a message, and updated the code to use them.I also removed unnecessary includes of render/plugin_messages.h from headers to speed up compiling.I moved the traits of IPC structs beside the struct definition to make it more apparent what's going on, so we avoid people modifying the struct and forgetting to update the traits.Amit: please look at chrome/test/automation/tab_proxy.ccMarc-Antoine: chrome/browser/printing/*Matt: the rest Review URL: http://codereview.chromium.org/20015 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9123 0039d316-1c4b-4281-b951-d872f2087c98
* Move proxy resolve requests out of plugin/renderer process, and into the ↵ericroman@google.com2009-01-311-0/+32
| | | | | | | | browser. Review URL: http://codereview.chromium.org/14142 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9006 0039d316-1c4b-4281-b951-d872f2087c98
* Fix a timing issue that caused gears to fail to load sometimes.mpcomplete@google.com2009-01-211-3/+5
| | | | | | | | BUG=http://b/issue?id=1559007 BUG=http://code.google.com/p/chromium/issues/detail?id=4219 Review URL: http://codereview.chromium.org/18604 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8417 0039d316-1c4b-4281-b951-d872f2087c98
* Make CommandLine into a normal object, with some statics for getting at the ↵evan@chromium.org2009-01-212-2/+2
| | | | | | | | | | | current process's command line. One explicit goal of this change is to *not* deal with the string/wstring issues at the API on POSIX; the functions are the same as before, which means they remain as broken as before. (I did try to fix the internals, though, so migrating the callers is now possible by adding platform-appropriate hooks.) Review URL: http://codereview.chromium.org/18248 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8347 0039d316-1c4b-4281-b951-d872f2087c98
* Generate all chrome .vcproj files:sgk@google.com2009-01-171-9/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Path name translation (/ to \) of various MSVSTool attributes. * Explicit keyword= arguments to MSVSProject. This will likely go away eventually in favor of uniform behavior. * Add a relative_path_substitutions array that can be used to substitute in Visual Studio variable like $(OutDir). * Add a local_directory_prefix that can be set to './' to only affect files in the current directory. * Additional Keyword ordering in Tool attributes to continue to match the default order Visual Studio generates. * Add a Derived() proxy class that can wrap a File node to tell the .vcproj generation that we want the derived file, not its source(s), in the file list. * In the individual *.scons files, add the necessary files (mostly .h files) to file lists, and update MSVSProject() calls with the additional necessary information. Result is identical .vcproj files modulo the following differences: * Four locales .vcproj files (da, en-US, he and zh-TW) with source file orders that don't match the other locale .vcproj files have re-ordered file lists to match the rest. * Cosmetic XML changes (white space, ending tags) in: chrome/app/chrome_dll.vcproj chrome/app/generated_resources.vcproj net/build/net_resources.vcproj * Removal or addition of ./ prefixes from various files that don't match the other file specifications within their individual .vcproj files: chrome/installer/util/util.vcproj net/build/net.vcproj net/build/net_unittests.vcproj * Add missing empty sections (<ToolFiles>, <References>, <Globals>) for consistency with other .vcproj files: chrome/tools/test/image_diff/image_diff.vcproj third_party/libpng/libpng.vcproj third_party/zlib/zlib.vcproj * Add missing RootNameSpace attribute: chrome/test/automation/automation.vcproj testing/gtest.vcproj * Use && instead of \r\n as a command separator, to sidestep XML-generation problems: chrome/app/chrome_exe.vcproj * Remove unnecessary (?) duplicate files in the file list: chrome/browser/views/browser_views.vcproj (event_utils.cc and event_utils.h were duplicated) Review URL: http://codereview.chromium.org/17603 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8253 0039d316-1c4b-4281-b951-d872f2087c98
* Improve scrolling performance when there are many windowed plugins in a page.jam@chromium.org2009-01-164-15/+34
| | | | | | | | 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
* Block Adobe Reader from issuing NPN_GetURL/NPN_GetURLRequests for URL ↵ananta@chromium.org2009-01-161-0/+13
| | | | | | | | schemes other than http/https/ftp. This mimics Firefox behavior and works around bug http://b/issue?id=1543405 which is a XSS vulnerability in the Adobe Reader plugin where it allows javascript in the parameters passed in to the URL.Bug=1543405R=jam Review URL: http://codereview.chromium.org/18070 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8159 0039d316-1c4b-4281-b951-d872f2087c98
* WaitableEvent is the replacement for Windows events. Previously in the code, ↵agl@chromium.org2009-01-156-16/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | a HANDLE from CreateEvent was used for signaling, both within a process and across processes. WaitableEvent is the cross platform replacement for this. To convert: * HANDLE -> base::WaitableEvent* * ScopedHandle -> scoped_ptr<base::WaitableEvent> * CreateEvent -> new base::WaitableEvent * SetEvent -> base::WaitableEvent::Signal * ResetEvent -> base::WaitableEvent::Reset * ObjectWatcher -> base::WaitableEventWatcher * WaitForMultipleObjects -> static base::WaitableEvent::WaitMany ObjectWatcher remains for Windows specific code. WaitableEventWatcher has an identical interface save, * It uses WaitableEvents, not HANDLEs * It returns void from StartWatching and StopWatcher, rather than errors. System internal errors are fatal to the address space IMPORTANT: There are semantic differences between the different platforms. WaitableEvents on Windows are implemented on top of events. Windows events work across process and this is used mostly for modal dialog support. Windows events can be duplicated with DuplicateHandle. On other platforms, WaitableEvent works only within a single process. In the future we shall have to replace the current uses of cross-process events with IPCs. BEWARE: HANDLE, on Windows, is a void *. Since any pointer type coerces to void *, you can pass a WaitableEvent * where a HANDLE is expected without any build-time errors. Review URL: http://codereview.chromium.org/16554 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8126 0039d316-1c4b-4281-b951-d872f2087c98
* New implementations of core plugin libraries.avi@google.com2009-01-151-1/+1
| | | | | | Review URL: http://codereview.chromium.org/17427 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8122 0039d316-1c4b-4281-b951-d872f2087c98
* 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
generated by cgit v1.1 at 2025-01-19 12:38:15 +0000