summaryrefslogtreecommitdiffstats
path: root/chrome/renderer
Commit message (Collapse)AuthorAgeFilesLines
* posix: don't register gears at all.evan@chromium.org2009-05-261-0/+3
| | | | | | | | | | | We currently register gears in JS-land, despite it not working in browser-land. We should disable it everywhere until it works. BUG=12529 Review URL: http://codereview.chromium.org/113870 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16943 0039d316-1c4b-4281-b951-d872f2087c98
* Fixing a long resource loading for small clipshclam@chromium.org2009-05-261-16/+18
| | | | | | | | | | | | The logic for resource loading for media file has a problem in determining the wait condition that it waited for one extra cycle (about ~5s) to know that the resource loading has completed, it is fixed in this patch. Also made clear about the logic in it. Review URL: http://codereview.chromium.org/113861 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16935 0039d316-1c4b-4281-b951-d872f2087c98
* Update renderers when there are zero user scripts.aa@chromium.org2009-05-261-1/+1
| | | | | | | | | | | | | Commit: http://codereview.chromium.org/113733 BUG=12170 TEST=Enable user scripts and create one. See that it runs. Now delete it. See that it does not run! Review URL: http://codereview.chromium.org/113741 Patch from Ted Crossman <tedoc2000@gmail.com>. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16864 0039d316-1c4b-4281-b951-d872f2087c98
* Rename |policy_url| to |first_party_for_cookies|. This now matches the ↵abarth@chromium.org2009-05-235-17/+18
| | | | | | | | | | | | WebKit name for this piece of data. R=jackson BUG=None TEST=No behavior change Review URL: http://codereview.chromium.org/115743 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16843 0039d316-1c4b-4281-b951-d872f2087c98
* Adds a RenderViewTest.PrintLayoutTest.hbono@chromium.org2009-05-238-11/+650
| | | | | | | | | | | | | | This change adds a new test 'RenderViewTest.PrintLayoutTest', which prints an HTML page and verify its output. To process a print job and verify its output, this change adds a pseudo-printer device "MockPrinter" into the MockRenderThread object. This MockPrinter object receives print-related IPC messages, process print jobs, and store the MD5 checksum of the output data. The current RenderViewTest.PrintLayoutTest retrieves the MD5 checksum values and just compare them with expected values. Nevertheless, please feel free to give me your ideas to improve this test. Finally, this change is inspired by PrintingLayoutTextTests (created by maruel) and a RenderViewTest.OnPrintPages (created by Mohamed Mansour). I would like to express my best gratitude to them. BUG=none TEST=none Review URL: http://codereview.chromium.org/100255 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16834 0039d316-1c4b-4281-b951-d872f2087c98
* CPAPI gears drag drop and renderer IPC.michaeln@google.com2009-05-222-3/+108
| | | | | | | | | | | | | | | CPAPI (0.10) functions for gears drag drop; one to extract thedrag type/data given an NPObject *event, one to override thedrop effect (drag cursor). Gears drag drop API receives a browser event as an NPObject* sothe event is untrusted. Provide IPC calls to the renderer sogears can pass the event to renderer/V8 for checking, prior todrag type/data extraction, or the setting of the drop effect. Original patch by Noel Gordon via: http://codereview.chromium.org/99240 BUG=7995 TEST=none Review URL: http://codereview.chromium.org/112056 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16808 0039d316-1c4b-4281-b951-d872f2087c98
* Introduce a buffer wait and timeout threshold for BufferedResourceLoaderhclam@chromium.org2009-05-222-175/+314
| | | | | | | | | | | | | | | | | | | | | The logic in the seek method of BufferedResourceLoader was that it will wait until the data is downloaded if we know that the desired seek position is within the bufferable range of the buffer, which is 10MB for now. This number is found to be too big and we should have another constant that governs the threshold of bytes that we should wait for forward seeking instead of starting a new request, this value is essentially much smaller than the buffer size, we guess this number to be 2MB. Also introduced the timeout logic to BufferedResourceLoader, so if BufferedResouceLoaderRead() takes more than a certain amount of time it is declared timeout and a new request should be started. The current timeout is set to 5s. Review URL: http://codereview.chromium.org/115627 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16793 0039d316-1c4b-4281-b951-d872f2087c98
* Remove the HistoryState property of WebRequest.darin@chromium.org2009-05-221-21/+31
| | | | | | | | | | | | | | | | | In the new WebKit API, it seems best if WebRequest is just a wrapper for WebCore::ResourceRequest since in most contexts that's what we need it to be. The solution here is to introduce a LoadHistoryState method on WebFrame that can be used to navigate to a session history item. BUG=10038 TEST=covered by existing back/forward navigation tests. R=brettw Review URL: http://codereview.chromium.org/113758 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16747 0039d316-1c4b-4281-b951-d872f2087c98
* Linux: add Breakpad supportagl@chromium.org2009-05-225-1/+124
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commits a rewrite of the Breakpad Linux client. The old code: * Had a number of plain bugs in it, but those could just have been fixed. * Allocated memory from the heap, which is a no go. * Made libc calls which can enter the dynamic linker - another source of crashes. * Didn't understand some of the tricks needed, like clone() via libc will write to random areas of memory because it assumes that it's only called from libpthread Additionally, we had one more requirement which meant changing the interface: * We need to be able to crash dump the renderers from the browser process. And that last one really needed a rewrite. We intend to try and upstream this new code into Breakpad. The new Breakpad design works like this: When a renderer crashes, a signal handler runs on an alternative stack and collects information about the registers of the thread before the crash. Then we enter Chromium specific code an send a datagram message to a magic file descriptor (4) containing: * the registers and tid of the crashing thread * the active URL * a file descriptor to a socket * a CREDENTIALS structure giving the PID of the renderer. On the other end of the socket is an object on the IO thread (render_crash_handler_host_linux.cc) which reads and parses the datagram. The CREDENTIALS structure is validated by the kernel, so the renderer can't lie about it's PID and try and get the browser to crash dump the wrong process. The browser then ptraces the renderer and extracts all the needed information to write a minidump to a temp file. Then we write a byte to the file descriptor which the renderer gave the browser in the datagram and that's the signal to the renderer to finish dying. It dies by sending itself the same signal which trigger the crash dump in the first place, so it will appear to crash as normal as far as kernel core dumps and waitpid are concerned. The browser then constucts a MIME message in a temp file for upload to the crash service. We then fork out to /usr/bin/wget to actually do the upload (since Debian numbers suggest that 99.8% of users have wget installed.) A second forked child unlinks the temp files once wget has completed. For a browser crash, everything works pretty much the same except that the datagram step is omitted and we clone() off a process to ptrace ourselves and write the minidump. This code is only enabled in Chrome branded builds. Stub source files are substituted in the case of a Chromium build. http://codereview.chromium.org/115526 BUG=9646,10772 TEST=Build a Chrome branded binary. Send SEGV to a renderer and verify that wget output appears on stderr. Send a SEGV to the main binary and verify the same. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16719 0039d316-1c4b-4281-b951-d872f2087c98
* 1)When we enabled breakpad on first run we weren't correctly setting the ↵jeremy@chromium.org2009-05-221-1/+1
| | | | | | | | | | | process type. 2)Fixed another logic inversion in SetActiveRendererURL. 3)Change IsCrashReporterEnabled-> IsCrashReporterDisabled to prevent future confusion since that was the question all the callers where askign anyway. Review URL: http://codereview.chromium.org/113737 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16707 0039d316-1c4b-4281-b951-d872f2087c98
* Add events to windowless plugins on linux. This CL also refactors the eventevan@chromium.org2009-05-222-5/+7
| | | | | | | | | | | | | communication between WebPlugin and WebPluginDelegate, to use a cross-platform message based on WebInputEvent. BUG=8202 TEST=A lot of manual testing on Linux and Windows, with Flash plugins and a custom plugin that dumps events on Linux. Review URL: http://codereview.chromium.org/115330 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16692 0039d316-1c4b-4281-b951-d872f2087c98
* Move ExtraData from WebRequest to WebDataSource.darin@chromium.org2009-05-212-67/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a DidCreateDataSource method to WebViewDelegate, which the embedder uses to know if their LoadRequest resulted in a navigation. The embedder then associates the ExtraData with the WebDataSource at that point. The WebDataSource then proceeds to be treated as the provisional data source, possibly failing or being committed. We then inspect WebFrame::GetDataSource in DidCommitLoadForFrame to recover the ExtraData. We have to take care to handle reference fragment navigations since those do not result in a new WebDataSource being created. So, in DidChangeLocationWithinPage, we update the ExtraData associated with the WebDataSource returned by WebFrame::GetDataSource. One thing that is important to note: In DidCommitLoadForFrame, we would previously always inspect the value of GetDataSource returned from the main frame instead of looking at the frame passed to DidCommitLoadForFrame. This explains why WebFrameImpl:: LoadRequest needed to cached ExtraData on the current WebDataSource, and I think doing so is awkward and wrong. My change is to always store the ExtraData on the first WebDataSource to be created as a result of LoadRequest. Then in DidCommitLoadForFrame, I always inspect the ExtraData from the given WebFrame. This means that for history navigations that only navigate a subframe, we'll end up with ExtraData associated with the WebDataSource of a subframe. I think this is OK even though the old code was trying to avoid this scenario. See the DCHECK removed in RenderView::UpdateURL. BUG=11423 R=brettw Review URL: http://codereview.chromium.org/115575 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16580 0039d316-1c4b-4281-b951-d872f2087c98
* Send the V8 histograms to UMAdavemoore@chromium.org2009-05-211-1/+5
| | | | | | Review URL: http://codereview.chromium.org/115183 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16558 0039d316-1c4b-4281-b951-d872f2087c98
* Prevent an extra copy of data types that get passed into IPC messages whenmpcomplete@google.com2009-05-201-1/+1
| | | | | | | | | | sending them. This makes it so that types sendable via IPC no longer need copy constructors. BUG=12296 Review URL: http://codereview.chromium.org/112042 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16497 0039d316-1c4b-4281-b951-d872f2087c98
* Add support for alternate window station.nsylvain@chromium.org2009-05-201-4/+35
| | | | | | | | | | TEST: Start chrome, make sure it loads pages, then user process explorer to make sure the WindowStation handle name is not the same as the browser process. BUG:10996 Review URL: http://codereview.chromium.org/113190 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16483 0039d316-1c4b-4281-b951-d872f2087c98
* Facilitate a FieldTrial in the rendererjar@chromium.org2009-05-202-13/+39
| | | | | | | | | | | | | | | | | | | | | | | I added a command line for the renderer that accepts a FieldTrial name and value, and forces that value to be activated in the renderer. As a result, any FieldTrial setting that is specified by the browser process can be set (forced) in the renderer process. Such settings can then be used to establish names of histograms, which means all processes can work in sync on a single field trial (and generate data). This should allow A/B tests to be run that modulate the page load times. Dave: Please review/confirm that you are happy with the changes to render_view.cc. Note that all I did was change the names and limits for the histograms (they now go up to 3 minutes). The MakeName() allows me to get an A/B test of the impact of DNS pre-resolution. Mike: Please review the code for passing along switch settings. r=davemoore,mbelshe Review URL: http://codereview.chromium.org/115525 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16460 0039d316-1c4b-4281-b951-d872f2087c98
* BufferedDataSource uses media::SeekableBufferhclam@chromium.org2009-05-202-173/+119
| | | | | | | | | | | Use SeekableBuffer as internal cache for BufferedResourceLoader. By switch to SeekableBuffer that supports short seek within buffered data in both backward and forward direciton. The amount of range request is greatly reduced. Review URL: http://codereview.chromium.org/115453 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16456 0039d316-1c4b-4281-b951-d872f2087c98
* Adds propagation and handling of render-side focus events, for the benefit ↵klink@chromium.org2009-05-202-3/+25
| | | | | | | | of assistive technologies (accessibility). Also cleans up the handling of WM_GETOBJECT in RenderWidgetHostViewWin and WidgetWin, as well as in BrowserAccessibilityManager. Review URL: http://codereview.chromium.org/115374 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16449 0039d316-1c4b-4281-b951-d872f2087c98
* Lookup the plugin for the mime type before attempting to open a channel for ↵ananta@chromium.org2009-05-191-14/+14
| | | | | | | | | | | | | | | | | the plugin. This ensures that the plugin will always be instantiated with the correct mime type at all times. Added plugin tests to cover this case where in the embed tag is specified with a URL but without a mime type. Fixes bug http://code.google.com/p/chromium/issues/detail?id=8973 Bug=8973 Test :- Added a plugin test for this case. Review URL: http://codereview.chromium.org/113326 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16414 0039d316-1c4b-4281-b951-d872f2087c98
* Fix Skia includes to use the whole path name.brettw@chromium.org2009-05-191-1/+1
| | | | | | Review URL: http://codereview.chromium.org/115412 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16374 0039d316-1c4b-4281-b951-d872f2087c98
* Fix a misaligmnet in rendering video frameshclam@chromium.org2009-05-191-2/+2
| | | | | | | | Misalignment if clip top is odd. Review URL: http://codereview.chromium.org/115499 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16358 0039d316-1c4b-4281-b951-d872f2087c98
* Fast paint for <video> by writing to SkCanvas directlyhclam@chromium.org2009-05-192-17/+193
| | | | | | | | | | | | | A direct path for rendering <video>, writes directly to bitmap in SkDevice in SkCanvas. There's several criteria for direct path: 1. No skew 2. SkDevice is ARGB8888 3. SkCanvas is opaque Review URL: http://codereview.chromium.org/115281 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16350 0039d316-1c4b-4281-b951-d872f2087c98
* Move WebMediaPlayerClientImpl files to WebKit API src location.darin@chromium.org2009-05-184-19/+10
| | | | | | | | | | | This involves adding a temporary glue function, which will be removed once WebFrame / WebView are part of the WebKit API. R=hclam Review URL: http://codereview.chromium.org/115482 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16336 0039d316-1c4b-4281-b951-d872f2087c98
* YUV with clipping.fbarchard@chromium.org2009-05-181-9/+10
| | | | | | | | | | | | All functions do 2 pixels at a time. 90 and 270 rotations implemented. YV16 refactored. YV12 code accepts a YuvType that allows the same code to support YV16 as well. Special case for half size removed. Special case for doubling added. 3.62 ms versus 8.62 for general purpose code. Review URL: http://codereview.chromium.org/113407 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16334 0039d316-1c4b-4281-b951-d872f2087c98
* Only send SelectionChanged events when the selection has actually changed.estade@chromium.org2009-05-182-1/+15
| | | | | | | | | | Webkit's giving us too many respondToChangedSelection calls, so we keep claiming the X clipboard which messes with selection in other programs and the omnibox. http://crbug.com/11956 Review URL: http://codereview.chromium.org/115468 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16321 0039d316-1c4b-4281-b951-d872f2087c98
* An adhoc fix for memory leak when playing a badly muxed video filehclam@chromium.org2009-05-172-9/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since the current data souce implementation for media resource loading assumes forward reading, when playing some badly muxed video files that has out-of-order read patterns a memory leak is observed. Here's the reason: 1. The video file has out-of-order read pattern 2. A lot of BufferedResourceLoader is created and destroyed to accomodate the seek requests that cannot be served by the buffer. 3. BufferedResourceLoader is not destroyed immediately when a new request is made, it is destroyed when the request has completed (triggered by cancelling the request). 4. Since request completion comes at a much lower rate than creation of BufferedResourceLoader, a lot of BufferedResourceLoader are remain alive and keep increasing, a leak is resulted. Adhoc solution: We can destroy all buffers in BufferedResourceLoader when it is called to stop. This can greatly reduce the leak amount. Although a lot of BufferedResourceLoader are still alive, they will be destroyed eventually (since a request completion is received due to cancelling of the request). A better solution would be to destroy the BufferedResourceLoader right away after it is stopped and fix the leak in ResourceDispatcher so we don't need to lengthen the lifetime of BufferedResourceLoader. CL for fixing ResourceDispatcher: http://codereview.chromium.org/115396 Review URL: http://codereview.chromium.org/115394 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16262 0039d316-1c4b-4281-b951-d872f2087c98
* extensions chrome.self.getViews():rafaelw@chromium.org2009-05-165-2/+108
| | | | | | | | | | extension toolstrips and background pages can now retrieve a list of the other "views" (window objects) in their extension and script them directly R=mpComplete Review URL: http://codereview.chromium.org/115419 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16222 0039d316-1c4b-4281-b951-d872f2087c98
* Shouldn't assume response code of 200 in SimpleDataSourcehclam@chromium.org2009-05-161-7/+12
| | | | | | | | | | | SimpleDataSource assumes the scheme is file or http and the response code is 200. We should just check if the response is successful using response.is_success() and verify the content_length, which will be -1 in case of unspecified length. Review URL: http://codereview.chromium.org/113422 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16217 0039d316-1c4b-4281-b951-d872f2087c98
* ChromeCanvas->gfx::Canvasben@chromium.org2009-05-151-2/+2
| | | | | | | | | | | Rename files too. TBR=brettw http://crbug.com/11387 Review URL: http://codereview.chromium.org/113443 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16148 0039d316-1c4b-4281-b951-d872f2087c98
* Uploaded & applied on behalf of Roger Tawa (rogerta@google.com).rafaelw@chromium.org2009-05-152-1/+4
| | | | | | | | | | | BUG=11200 R=aa,rafaelw http://codereview.chromium.org/115250 Review URL: http://codereview.chromium.org/113442 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16146 0039d316-1c4b-4281-b951-d872f2087c98
* A few quick fixes to SimpleDataSource.scherkus@chromium.org2009-05-142-12/+13
| | | | | | | | | Total bytes and buffered bytes weren't being set and a DCHECK was firing when loading files when it really shouldn't have. Review URL: http://codereview.chromium.org/113385 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16092 0039d316-1c4b-4281-b951-d872f2087c98
* Change VideoRendererImpl to use VideoThread as opposed to VideoRendererBase.scherkus@chromium.org2009-05-142-17/+34
| | | | | | | | Now with less jitter! Review URL: http://codereview.chromium.org/115358 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16087 0039d316-1c4b-4281-b951-d872f2087c98
* Revert "Revert "implemented extensions api windows.update().""aa@chromium.org2009-05-143-2/+104
| | | | | | | | | | This reverts commit 81242e3b9c6e6fbc42ccf5f973b27ed4cf4401d6. This wasn't the cause of the breakage. Review URL: http://codereview.chromium.org/115337 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16032 0039d316-1c4b-4281-b951-d872f2087c98
* Revert "implemented extensions api windows.update()."aa@chromium.org2009-05-143-104/+2
| | | | | | | | This reverts commit f2d9a44f3886aeab1378c8dbc1ce445202bc0ca5. Review URL: http://codereview.chromium.org/115335 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16030 0039d316-1c4b-4281-b951-d872f2087c98
* implemented extensions api windows.update().rafaelw@chromium.org2009-05-143-2/+104
| | | | | | | | | | | | | currently only supports {left, top, width, height}. Also, added extensions_api_client_unittest tests for CreateWindow, UpdateWindow & RemoveWindow BUG=11200 R=mpComplete Review URL: http://codereview.chromium.org/115316 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16029 0039d316-1c4b-4281-b951-d872f2087c98
* Retry r16006.estade@chromium.org2009-05-141-1/+1
| | | | | | Review URL: http://codereview.chromium.org/113369 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16025 0039d316-1c4b-4281-b951-d872f2087c98
* revert r16006 due to msvc warning.estade@chromium.org2009-05-131-1/+1
| | | | | | | | TBR=playmobil Review URL: http://codereview.chromium.org/113367 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16007 0039d316-1c4b-4281-b951-d872f2087c98
* Properly convert from UTF8 to UTF16 in WebTextInputImpl.estade@chromium.org2009-05-131-1/+1
| | | | | | | | | String util changes by darin@chromium.org. BUG=11699 Review URL: http://codereview.chromium.org/115215 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16006 0039d316-1c4b-4281-b951-d872f2087c98
* Re-do r15244 again.darin@chromium.org2009-05-132-32/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Originally reviewed at http://codereview.chromium.org/100353 Eliminate webkit/glue/webhistoryitem* in favor of adding a NavigateBackForwardSoon method WebViewDelegate. This moves all of the hacky details of how we intercept "history.{back, forward,go}" into the webkit layer. My eventual plan is to teach WebCore how to make this not hacky. In this version of the CL, TestWebViewDelegate performs the back/forward navigation directly in NavigateBackForwardSoon instead of using PostTask to delay it. I'm doing this to minimize regressions so that I can hopefully get the rest of this CL landed. I also already made the changes to WebKit to force history. {back,forward,go} to be processed asynchronously. Finally, it was necessary to move DumpBackForwardList out of webkit_glue.cc since it was using itemAtIndex to generate those results, and now that we return synthetic URLs for that function, the results were very wrong. The fix is to move DumpBackForwardList into TestShell so that it can more directly inspect the TestNavigationController. Now, it is necessary for webkit_glue.h to expose a function to dump a content state string (aka a WebCore::HistoryItem). BUG=11423 R=mpcomplete Review URL: http://codereview.chromium.org/113328 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15997 0039d316-1c4b-4281-b951-d872f2087c98
* Propagate intrinsic width notification over IPC in all cases (not just ↵pinkerton@chromium.org2009-05-132-7/+33
| | | | | | | | extensions) to the TabContentsView. Enable the zoom button on Mac to utilize it. Ensure we only send the IPC notification when the value changes, as WebCore tends to over-report that it has changed. Fix const-ness in delegate API where it's not necessary. Review URL: http://codereview.chromium.org/115138 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15988 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting 15986.michaeln@google.com2009-05-132-63/+2
| | | | | | Review URL: http://codereview.chromium.org/113359 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15987 0039d316-1c4b-4281-b951-d872f2087c98
* CPAPI gears drag drop and renderer IPC....michaeln@google.com2009-05-132-2/+63
| | | | | | | | | | | | | | | | | | | | | | CPAPI (0.10) functions for gears drag drop; one to extract the drag type/data given an NPObject *event, one to override the drop effect (drag cursor). Gears drag drop API receives a browser event as an NPObject* so the event is untrusted. Provide IPC calls to the renderer so gears can pass the event to renderer/V8 for checking, prior to drag type/data extraction, or the setting of the drop effect. V8 event checking is a TODO(noel), http://mondrian/10947778 for the CPAPI (0.10) change submitted to gears. BUG=7995 Original patch by Noel Gordon via: http://codereview.chromium.org/99240 Review URL: http://codereview.chromium.org/115280 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15986 0039d316-1c4b-4281-b951-d872f2087c98
* This CL updates chrome to the latest version of skia, retrieved via DEPS, andsenorblanco@chromium.org2009-05-133-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | placed in third_party. All relevant skia changes (for all 3 platforms) have been upstreamed. Most of this CL is mind-numbingly repetitive. Things of interest are: skia.gyp (now points at third_party versions), DEPS, and SkUserConfig.h. stdint.h: Skia now requires C99 integer types, which MSVC doesn't support natively. I have put typedefs in config/win/stdint.h. Note that the new version of skia appears to render rects whose coordinates are "backwards" (ie., x2 < x1 or y2 < y1), which were formerly culled. There were a couple obvious instances of this in the code which I fixed, but there may be more. There were ~35 layout test failures due to minor pixel differences which I rebaselined on Windows and Linux, and 8 genuine failures related to masks and stroked text, which I have put in text_expectations.txt and assigned to myself. (There was another change which broke ~1700 tests on each platform, but I put that change behind an #ifdef for now). R=brettw Review URL: http://codereview.chromium.org/65012 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15949 0039d316-1c4b-4281-b951-d872f2087c98
* DevTools: enable out of process dev tools by default. Take 2.pfeldman@chromium.org2009-05-133-4/+9
| | | | | | Review URL: http://codereview.chromium.org/115292 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15947 0039d316-1c4b-4281-b951-d872f2087c98
* Revert r15940 again. Unexpected layout test failures :(darin@chromium.org2009-05-132-2/+32
| | | | | | | TBR=mpcomplete git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15942 0039d316-1c4b-4281-b951-d872f2087c98
* Re-do r15244 again.darin@chromium.org2009-05-132-32/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Originally reviewed at http://codereview.chromium.org/100353 Eliminate webkit/glue/webhistoryitem* in favor of adding a NavigateBackForwardSoon method WebViewDelegate. This moves all of the hacky details of how we intercept "history.{back, forward,go}" into the webkit layer. My eventual plan is to teach WebCore how to make this not hacky. In this version of the CL, TestWebViewDelegate performs the back/forward navigation directly in NavigateBackForwardSoon instead of using PostTask to delay it. I'm doing this to minimize regressions so that I can hopefully get the rest of this CL landed. I also already made the changes to WebKit to force history. {back,forward,go} to be processed asynchronously. BUG=11423 TBR=mpcomplete Review URL: http://codereview.chromium.org/115288 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15940 0039d316-1c4b-4281-b951-d872f2087c98
* Add Automatic spell correction support in Chrome.sidchat@google.com2009-05-122-0/+11
| | | | | | | Issue=7624 Review URL: http://codereview.chromium.org/42608 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15888 0039d316-1c4b-4281-b951-d872f2087c98
* cleanup pending_extension_requests_ in dtor.rafaelw@chromium.org2009-05-121-0/+7
| | | | | | | | | | | pending requests never get cleared in extension_api_client_tests, so they were causing a memory leak. BUG=11809 R=erikkay Review URL: http://codereview.chromium.org/112018 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15883 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting 15843: chrome performance regression.pfeldman@chromium.org2009-05-123-9/+4
| | | | | | Review URL: http://codereview.chromium.org/113284 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15879 0039d316-1c4b-4281-b951-d872f2087c98
* FormatErrorMessage() functions are now publicly available from ↵rafaelw@chromium.org2009-05-127-80/+146
| | | | | | | | | | | | ExtensionErrorUtils. ExtensionTabsModule implements a bunch of error_messages. Extension Calls now always deliver a response to the calling context and route error messages if any to the window.console.error log. Review URL: http://codereview.chromium.org/113105 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15853 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-02-09 01:21:25 +0000