summaryrefslogtreecommitdiffstats
path: root/chrome_frame/bind_context_info.cc
Commit message (Collapse)AuthorAgeFilesLines
* Include base/win/scoped_comptr.h instead of base/scoped_comptr_win.h.tfarina@chromium.org2011-04-121-3/+3
| | | | | | | | | | | | | | | | | Fix up all the callers to use the new location and namespace. Also, delete the stub file since it isn't included by anyone more. (Note: This was a TODO for brettw). BUG=None TEST=None R=brettw@chromium.org Review URL: http://codereview.chromium.org/6825055 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@81303 0039d316-1c4b-4281-b951-d872f2087c98
* Download requests in ChromeFrame which occur in response to a POST request ↵ananta@chromium.org2011-02-281-1/+0
| | | | | | | | | | | | | | | | | | | | | | need to pass the post data as well while reissuing the navigation. This ensures that a POST request is correctly sent out at all times instead of a GET request. While the assumption is that reusing the bind context would achieve this behavior, it does not appear to be true at all times. While fixing this I also found that reissuing a navigation via a NavigateWithBindCtx call causes the current chrome frame document to receive an Unload call at times, leading to the page being rendered useless after the request finishes. We should reissue the navigation on a new window to work around this problem. Fixes bug http://code.google.com/p/chromium/issues/detail?id=73985 BUG=73985 TEST=As described in the bug. Review URL: http://codereview.chromium.org/6598016 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@76282 0039d316-1c4b-4281-b951-d872f2087c98
* If we switch into ChromeFrame as a result of a redirect then we need to ↵ananta@chromium.org2011-02-221-0/+7
| | | | | | | | | | | | | | | | | | | | | navigate chrome to the correct URL to ensure that scripts on the page see the correct URL. This functionality regressed when the protocol sink patch landed. Fix is to read the URL from the ProtData object which wraps the underlying protocol sink, when our active document loads. Removed stale code from the Chromeframe moniker patch which eventually needs to go. Fixes bug http://code.google.com/p/chromium/issues/detail?can=2&q=71860 BUG=71860 TEST=As described in the bug. Review URL: http://codereview.chromium.org/6469103 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@75656 0039d316-1c4b-4281-b951-d872f2087c98
* Second attempt at trying to land buggy bho avoidance: ↵tommi@chromium.org2010-07-211-1/+2
| | | | | | | | | | | | | | | | | | http://codereview.chromium.org/3031009 A different approach to avoid crashes in buggy 3rd party BHOs.This time we're more preceise and only target the buggy components.Behaviour for components that handle browser events correctly, is unchanged even in the presence of buggy DLLs.The core class here is the BuggyBhoTls class and here's the comment for that class: // Construct an instance of this class on the stack when firing web browser // events that can be sent to buggy BHOs. This class will intercept those // BHOs (see list in cc file) and ignore notifications to those components // for as long as the BuggyBhoTls instance on the stack lives. TEST=A better fix for bug 44463 but also fixes bug 49373 and a number of crashes that haven't been associated with bug reports yet. BUG=44463, 49373 Review URL: http://codereview.chromium.org/3053008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@53236 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 53194 - A different approach to avoid crashes in buggy 3rd party ↵sanjeevr@chromium.org2010-07-211-2/+1
| | | | | | | | | | | | | | | | | | BHOs.This time we're more preceise and only target the buggy components.Behaviour for components that handle browser events correctly, is unchanged even in the presence of buggy DLLs.The core class here is the BuggyBhoTls class and here's the comment for that class: // Construct an instance of this class on the stack when firing web browser // events that can be sent to buggy BHOs. This class will intercept those // BHOs (see list in cc file) and ignore notifications to those components // for as long as the BuggyBhoTls instance on the stack lives. TEST=A better fix for bug 44463 but also fixes bug 49373 and a number of crashes that haven't been associated with bug reports yet. BUG=44463, 49373 Review URL: http://codereview.chromium.org/3031009 TBR=tommi@chromium.org git-svn-id: svn://svn.chromium.org/chrome/trunk/src@53197 0039d316-1c4b-4281-b951-d872f2087c98
* A different approach to avoid crashes in buggy 3rd party BHOs.This time ↵tommi@chromium.org2010-07-211-1/+2
| | | | | | | | | | | | | | | | we're more preceise and only target the buggy components.Behaviour for components that handle browser events correctly, is unchanged even in the presence of buggy DLLs.The core class here is the BuggyBhoTls class and here's the comment for that class: // Construct an instance of this class on the stack when firing web browser // events that can be sent to buggy BHOs. This class will intercept those // BHOs (see list in cc file) and ignore notifications to those components // for as long as the BuggyBhoTls instance on the stack lives. TEST=A better fix for bug 44463 but also fixes bug 49373 and a number of crashes that haven't been associated with bug reports yet. BUG=44463, 49373 Review URL: http://codereview.chromium.org/3031009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@53194 0039d316-1c4b-4281-b951-d872f2087c98
* Addressing review comment from Stoyan (remove one dlog statement).tommi@chromium.org2010-05-191-3/+0
| | | | | | | | | | TEST=none BUG=none TBR=stoyan Review URL: http://codereview.chromium.org/2102010 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@47691 0039d316-1c4b-4281-b951-d872f2087c98
* Candidate fix for bug 44108. The FromBindContext function was inherently ↵tommi@chromium.org2010-05-141-19/+24
| | | | | | | | | | | | | racy as it returned a pointer to a non-addrefed pointer and the AddRef/Release implementation in the BindContextInfo was not thread safe. Also fixed BSCBStorageBind object leak. TEST=See bug description BUG=44108 Review URL: http://codereview.chromium.org/2080005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@47306 0039d316-1c4b-4281-b951-d872f2087c98
* Use an interface to get to the C++ object pointer instead of casting directly.tommi@chromium.org2010-05-131-3/+36
| | | | | | | | | | | The object was being marshalled so, we were casting an ole32 proxy object to our implementation. To avoid marshalling altogether I'm also using the FTM. So, yeah, we're going belt and suspenders. TEST=See bug. BUG=43988 Review URL: http://codereview.chromium.org/2011016 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@47160 0039d316-1c4b-4281-b951-d872f2087c98
* Avoid a crash in ChromeFrame in the BindToStorage call initiated when our ↵ananta@chromium.org2010-04-151-0/+45
active document is loaded. The crash occurs while dereferencing a NULL delegate which is the case in the pending request object created by the active document to handle the initial load. Fix for this is to maintain a pending state in the request object. We ignore all OnProgress notifications in this state. When Chrome requests data for the top level url this state is cleared. Consolidated the number of bind context information structures into one which contains everything we need in ChromeFrame, i.e. to decide to switch to Chrome, indicating whether the request came from Chrome, etc. Review URL: http://codereview.chromium.org/1654012 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@44604 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-02-07 20:17:40 +0000