summaryrefslogtreecommitdiffstats
path: root/chrome/renderer/render_view.cc
Commit message (Collapse)AuthorAgeFilesLines
* This fixes http://code.google.com/p/chromium/issues/detail?id=205, which was ↵ananta@chromium.org2008-10-201-1/+25
| | | | | | | | | | | | | an issue with a windowed flash instance not rendering content at times.The bug occurs as a result of the following:-1. The flash plugin executes a script via GetURLNotify. This script calls window.open with the target as self, which shows up as a new tab in the browser. This causes a new RenderView object to be instantiated (See RenderView::CreateWebView).2. RenderView::CreateWebView sends over the ViewHostMsg_CreateWindow IPC message to the browser. The handler in the browser sends over an ack for this message with the window handle. This is used as the parent window for any plugins instantiated in the page.3. At times, the newly created view starts receiving data which is processed before the ViewMsg_CreatingNew_ACK message is received and processed by the view. This causes the plugin to be instantiated without a parent window thus ending up as a top level window.The fix is to queue up resource messages and process them after we receive the ack for the ViewHostMsg_CreateWindow IPC. Tests :- Covered by UI tests. R=jam Review URL: http://codereview.chromium.org/7514 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@3631 0039d316-1c4b-4281-b951-d872f2087c98
* Remove throttling code from the Browser process and implement throttling in ↵erg@google.com2008-10-171-7/+40
| | | | | | | | | | | | | the Renderer. The previous way of doing throttling was just calling CloseContents() on a window to reject it. But since the Browser is notified about a window opening asynchronously, by the time the CloseContents() sends a message back to the Renderer, a bunch more windows have been opened, leading to memory exhaustion. Instead, make all RenderViews created from a parent RenderView share a counter and start refusing to create RenderViews if too many RV have been created. Every RenderView (except for the first one) is assumed to be an unrequested popup, until notified by the Browser process by either a ViewMsg_DisassociateFromPopupCount message (this RenderView is a new top level page) or a ViewMsg_DisassociatePopup message (this RenderView is a requested popup and therefore shouldn't count against the count.) BUG=3382, 2632 Review URL: http://codereview.chromium.org/7388 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@3568 0039d316-1c4b-4281-b951-d872f2087c98
* Separate out most view creation from WebContents. This adds a new ↵brettw@google.com2008-10-171-2/+2
| | | | | | | | sub-delegate to RenderViewHostDelegate which is implemented by WebContentsView. I did a lot of plumbing and moving around as a result. Review URL: http://codereview.chromium.org/6608 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@3527 0039d316-1c4b-4281-b951-d872f2087c98
* Adds a bit of Greasemonkey support hidden behind the --enable-greasemonkey ↵aa@google.com2008-10-161-1/+16
| | | | | | | | | | | | | flag. Implementation follows the pattern of the visited links system. Things still to be done: - stop using a hardcoded script directory - watch script directory and update shared memory when necessary - move file io to background thread - support for @include patterns -- now, all scripts are applied to all pages Review URL: http://codereview.chromium.org/7254 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@3496 0039d316-1c4b-4281-b951-d872f2087c98
* This fixes http://code.google.com/p/chromium/issues/detail?id=146&,ananta@chromium.org2008-10-161-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | which was an issue with navigation attempts initiated by Flash not working correctly in Chrome. The plugin would initiate a navigation in response to a user click. This would eventually result in a call to a script on the page, which would query the history in a timer, and would end up resetting the selected URL to the original URL as the history length would not be updated as yet. The reason being the following:- 1. A Frame navigation is initiated by the renderer in response to the user click. 2. This is sent as an async message to the browser UI thread. 3. When the navigation in the browser completes we update the history info in render view asynchronously. The fix is to attempt to update the history count when we receive notifications from webkit. These include notifications for items being added to the history, navigations based on history (like history.back/forward/goto, etc). These counts continue to be updated as before from the browser as well. Added UI tests to test these cases. Bug=146 R=jam Review URL: http://codereview.chromium.org/7412 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@3457 0039d316-1c4b-4281-b951-d872f2087c98
* Add an alternate error page for connection errors. This is already ↵tc@google.com2008-10-151-11/+27
| | | | | | | | | | | | supported by Link Doctor, we just didn't have it at the time we implemented it. ERR_CONNECTION_FAILED is from winhttp and ERR_CONNECTION_REFUSED is from new-http. These error codes seem to only be used in one or the other. http://b/1359790 Review URL: http://codereview.chromium.org/7119 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@3410 0039d316-1c4b-4281-b951-d872f2087c98
* Rename various text zoom related stuff to be more generic, since we now canbrettw@google.com2008-10-141-10/+11
| | | | | | | | | | optionally zoom the page. I added an easy way in render_view to toggle between text zoom and full page zoom, and allowed the embedder to specify this in the glue layer. This allows me to fix the text zoom layout test, which specifically asks that the text be zoomed. Review URL: http://codereview.chromium.org/7320 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@3377 0039d316-1c4b-4281-b951-d872f2087c98
* Patch by Thatcher Ulrich <tulrich@google.com>.ojan@google.com2008-10-091-1/+1
| | | | | | | | | | | | | | | Implement "iframe shim" behavior for windowed plugins. In FF and IE on windows, iframes are implemented as native HWNDs. This has the side effect that iframes display on top of windowed plugins. This side effect has long been known as a workaround for allowing HTML elements to appear above plugin content. BUG=1788 Review URL: http://codereview.chromium.org/7032 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@3137 0039d316-1c4b-4281-b951-d872f2087c98
* Merge the chrome_webkit_merge_branch back on to trunk. This brings ustc@google.com2008-10-011-0/+3
| | | | | | | up to webkit@36102. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2778 0039d316-1c4b-4281-b951-d872f2087c98
* Adds MSAA/IAccessible exposure of web content.klink@chromium.org2008-09-301-4/+35
| | | | | | Review URL: http://codereview.chromium.org/4057 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2738 0039d316-1c4b-4281-b951-d872f2087c98
* While testing I hit a DCHECK on line 1643 (because of a UMR).finnur@google.com2008-09-291-1/+1
| | | | | | Review URL: http://codereview.chromium.org/3406 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2703 0039d316-1c4b-4281-b951-d872f2087c98
* Factor out a RenderThread interfacecpu@google.com2008-09-261-2/+3
| | | | | | | | | | | - RenderWidget was not unit testable as it was - Adding the first ever RederWidget unit tests It is possible to do more. Taking it step by step. Review URL: http://codereview.chromium.org/4271 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2649 0039d316-1c4b-4281-b951-d872f2087c98
* Fix bug 455: Active match in Find is not selected and links are not focused ↵finnur@google.com2008-09-261-1/+1
| | | | | | | | after you close the Find box. Review URL: http://codereview.chromium.org/4283 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2645 0039d316-1c4b-4281-b951-d872f2087c98
* This CL adds new UI tests for the SSL UI.jcampan@chromium.org2008-09-241-0/+1
| | | | | | | | | | | | | | | | | | | | 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
* This CL enables the Page info menu when right-clicking on a page/frame.jcampan@chromium.org2008-09-231-1/+3
| | | | | | | | | | For the frame case, the SSL info had to be added to the show menu message (as the navigation entry contains the top frame SSL info). BUG=2467 TEST=Open a page over HTTPS with multiple frames. Right-click and select shot page info. Review URL: http://codereview.chromium.org/4034 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2504 0039d316-1c4b-4281-b951-d872f2087c98
* Revert the change that fixed the encoding when viewing source in subframes.brettw@google.com2008-09-121-15/+5
| | | | | | | | | This makes view source for some pages (for example Google Reader) not work properly. I speculate that telling WebKit to change the encoding (which causes a reload) right after starting the real load makes it confused. Review URL: http://codereview.chromium.org/3022 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2143 0039d316-1c4b-4281-b951-d872f2087c98
* Don't index https content. This uses the toplevel brettw@google.com2008-09-091-0/+9
| | | | | | Review URL: http://codereview.chromium.org/1646 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1927 0039d316-1c4b-4281-b951-d872f2087c98
* Made changes to the JavaScript debugger in preparing for an upcomingsgjesse@google.com2008-08-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | change in V8 where the implicit breaks currently issued when receiving a command while running will be removed. To get in contact with the V8 debugging interface and send messages V8 needs to be in the break state. Getting V8 into the break state will be the responsebility of the debugger using the V8 debugging interface. Changed the messages between the renderer and the debugger. There are now explicit messages for break and detach. Alse renamed the SendToDebugger message to DebugCommand. There is now messages DebugAttach, DebugBreak, DebugCommand and DebugDetach. The message DebugBreak has a force flag to indicate whether the renderer should issue some JavaScript to help the break along or whether it should just schedule a break to happen whenever JavaScript executes. Removed the artificial attach JSON response send by the renderer and replaced that with an on debug attach call to the debugger shell. This call is reouted to the on_attach function in the debugger JavScript code. Changed the debugger to issue break requests whenever a suitable command, e.g. setting a break point, is issued. In this case a flag is used to track whether execution should be automatically resumed after the command have been send to the V8 debugger interface. Changed the handling of the plain break event to not force a break by executing additional JavaScript. Thereby a plain break does not break JavaScript execution until code on the tab beeing debugged is actually executed. Set the command name explicitly on all commands. Removed parseSimpleCommand as it was just used for the the continue command for which an explicit parseContinueCommand has been added. Removed the last_command field from DebugShell as it was not used. Updated the debugger protocol test to reflect the removed attach event. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1526 0039d316-1c4b-4281-b951-d872f2087c98
* Simplify OneShotTimer and RepeatingTimer. Fix up all consumers.darin@google.com2008-08-281-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | Major changes: OneShotTimer and RepeatingTimer become template classes that no longer require a Task or a Timer object. They just use PostDelayedTask. Under the hood that still uses a Timer object. The API is much simpler for consumers as they now no longer need to worry about allocating a Task or managing the lifetime of the object pointer held by the Task. I added some new unit tests to timer_unittest.cc to cover the API. I preserved the old TimerManager / Timer API for now, but I plan to soon kill it. R=brettw BUG=1346553 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1502 0039d316-1c4b-4281-b951-d872f2087c98
* This call is incorrect because calling it here allows any subframe to update ↵mmoss@google.com2008-08-281-4/+0
| | | | | | | | | | "is_loading_", which represents state on the main frame, and thus should only be updated to reflect changes to that frame (as ProgressTracker is careful to do by testing "m_originatingProgressFrame"). It's also redundant because it is already triggered through the ProgressTracker, even when there is a ProvisionalLoad error. This fixes issues where the favicon for a page was not being loaded because of errors in subframes. BUG=1186854 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1495 0039d316-1c4b-4281-b951-d872f2087c98
* Second attempt to fix p13n breakage.ericcheng@google.com2008-08-261-0/+2
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1361 0039d316-1c4b-4281-b951-d872f2087c98
* Fix build break caused by some functions not ifdef CHROME_PERSONALIZATION'd out.ericcheng@google.com2008-08-261-0/+4
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1360 0039d316-1c4b-4281-b951-d872f2087c98
* Some more glue code for the personalization module.ericcheng@google.com2008-08-261-0/+13
| | | | | | | | Added ability to invoke a method on an NPObject wrapped in a CppVariant. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1359 0039d316-1c4b-4281-b951-d872f2087c98
* Use a more compact license header in source files.license.bot2008-08-241-28/+4
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1287 0039d316-1c4b-4281-b951-d872f2087c98
* Code review changes. Incorporated all the suggestions from previous review. joshia@google.com2008-08-211-10/+15
| | | | | | | | | | | | | One item not changed yet is to rename 'receiver' in ForwardMessageToExternalHost. The idea is to invoke receiver("message") at the other end. So for example if the args to ForwardMessageToExternalHost("hello", "world") then we will invoke a script hello("world") on the other side. 'receiver' doesn't really describe the first argument here so if there is a better suggestion, I would be happy to change it :) git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1176 0039d316-1c4b-4281-b951-d872f2087c98
* As Brett pointed it out, We normally use 8-bit for encoding names since ↵jnd@google.com2008-08-211-3/+3
| | | | | | they're always ASCII. Plus, wstrings will also be 32-bit characters on Linux and Mac, which is expensive. So I make this CL by using std::string instead of std::wstring every time you have an encoding name. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1144 0039d316-1c4b-4281-b951-d872f2087c98
* The CL is consist of CLs(1624,1580) for bug:1281734 which are reviewed and ↵jnd@google.com2008-08-181-1/+10
| | | | | | | | | LG by brett. I just merge them to single one for passing compilation. The CL is to fix bug http://b/issue?id=1281734. FireFox uses encoding used by the original webpage to decode the source of the webpage, Chrome does not. We need to add a new parameter which carries the override encoding when opening a view-source URL for viewing its source. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@997 0039d316-1c4b-4281-b951-d872f2087c98
* Added support for PostMessage from the automation framework toiyengar@google.com2008-08-151-0/+25
| | | | | | | the renderer. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@964 0039d316-1c4b-4281-b951-d872f2087c98
* Code to facilitate sending message to external host.joshia@google.com2008-08-151-0/+5
| | | | | | | | | | Note that at this time the parameters to the message are still tentative. The call goes as a sync call from renderer to the browser. From then onwards it happens async and no return value is available yet. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@957 0039d316-1c4b-4281-b951-d872f2087c98
* Copy from http://chrome-reviews.prom.corp.google.com/1237 (new gcl ↵timsteele@google.com2008-08-151-0/+12
| | | | | | | | | | | | | | | | | | | changelist model). Description was: Conditionally include personalization/ code by surrounding the hooks into this module with #ifdef CHROME_PERSONALIZATION in various .h/.cc files. Building with the module requires adding this macro as a preprocessor definition in build/internal/essential.vsprops, and adding it to the VCResourceCompiler tool's command line (using /d). We will try and make this easier in the future. TBR=darin git-svn-id: svn://svn.chromium.org/chrome/trunk/src@955 0039d316-1c4b-4281-b951-d872f2087c98
* Step 1 at making Gears run in the renderer process (enabled by switchmpcomplete@google.com2008-08-151-1/+20
| | | | | | | | | "--gears-in-renderer"). Requires some changes to gears to work. Most things work if you disable the sandbox. One major hole is that update tasks don't report status to the appropriate renderer. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@954 0039d316-1c4b-4281-b951-d872f2087c98
* git-svn-id: svn://svn.chromium.org/chrome/trunk/src@873 ↵awalker@google.com2008-08-141-4/+4
| | | | 0039d316-1c4b-4281-b951-d872f2087c98
* A bunch of cleanups to beforeunload/unload handling.ojan@google.com2008-08-021-8/+4
| | | | | | | | 1. Remove all the is_closing_browser plumbing. WebContents/TabContents/RenderViewHost/etc really shouldn't (and don't!) need to know anything about whether we're closing the browser or not. 2. Refactor the handling of beforeunload/unload state in browser.cc. I think this makes it considerably easier to reason about the correctness of it. 3. Added a couple TODOs for future cleanups that would have made this change a bit too large. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@273 0039d316-1c4b-4281-b951-d872f2087c98
* Fix DCHECK in history_backend by ensuring we clear redirect tracking state ↵timsteele@google.com2008-08-011-1/+6
| | | | | | | | | | | | | whenever the RenderView is told that a provisional load has started for the main frame. The DCHECK(params->referrer == params->redirects[0]) was firing because: a) page A was loaded, triggered WillPerformClientRedirect b) after the provisional load started for the destination page of A's client redirect, but before this load was committed, the browser makes a Navigation request for page B. c) When page B's load is committed, the RenderView's completed_client_redirect_src_ was still set, resulting in a CLIENT_REDIRECT transition type and forwarding the src value through params->referrer -- but params->redirects was now completely unrelated. Kaboom. This fix should be general enough to handle cases (that are relatively likely in the wild) where WebKit legitimately cancels the redirect, instead of just the browser doing so. Note we can't depend on dispatchDidCancelClientRedirect because we get that callback on both completion and cancellation of a client redirect. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@251 0039d316-1c4b-4281-b951-d872f2087c98
* Add chrome to the repository.initial.commit2008-07-261-0/+2469
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-06-08 21:02:22 +0000