summaryrefslogtreecommitdiffstats
path: root/chrome_frame/bho.h
Commit message (Collapse)AuthorAgeFilesLines
* 3rd try. *sigh*slightlyoff@chromium.org2010-03-261-0/+14
| | | | | | | | | | | | | See: http://codereview.chromium.org/858003 TBR=tommi BUG=22846 TEST=On IE 8, clear the cache entirely, watch GCF launch (via task manager) Review URL: http://codereview.chromium.org/1343004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42732 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting this CL to see if this fixes chrome frame unit test failures.ananta@chromium.org2010-03-251-14/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Revert 42684 - Implements IDeleteBrowsing history and moves the GCF profile into the IE TIF directory for nonpriv mode users on IE < 8. Implementation notes: Earlier work enabled InPrivate browsing detection and mapped it to creation of an incognito profile instance.Privacy features and how they operate with this change: "Delete Browsing History": IE 6 & 7: all history (including databases) is deleted if cache is cleared *WITHOUT* an active Chrome process holding references to the profile resources. If GCF is rendering a page when the cache is cleared, history *WILL NOT* be deleted on the GCF side, however GCF will continue to operate and IE will remove all other history artifacts as usual. IE 8: GCF cache is cleared in alignment with the options specified by the user. Clearing Temporary Internet Files may destroy the profile entirely, and so we need to consider not moving the GCF profile on IE 8. "InPrivate Filtering": IE 8 (only): more testing required. "InPrivate Browsing": IE 8 (only): pages rendered in GCF *after* entering InPrivate mode are not persisted to disk (use an incognito wrapper on the specified profile). Currently displayed pages are not effected by the switch, although refreshing them will invoke the new behavior. Generally speaking, BHO's are disabled by IE 8 while in InPrivate mode, so entering this state is wonky to begin with but we handle it as well as can be expected. BUG=22846 TEST=On IE 8, clear the cache entirely, note GCF entries in DbgView (better tests coming) Review URL: http://codereview.chromium.org/858003 TBR=slightlyoff@chromium.org Review URL: http://codereview.chromium.org/1353002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42691 0039d316-1c4b-4281-b951-d872f2087c98
* Implements IDeleteBrowsing history and moves the GCF profile into the IE TIF ↵slightlyoff@chromium.org2010-03-251-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | directory for non-priv mode users on IE < 8. Implementation notes: Earlier work enabled InPrivate browsing detection and mapped it to creation of an incognito profile instance.Privacy features and how they operate with this change: "Delete Browsing History": IE 6 & 7: all history (including databases) is deleted if cache is cleared *WITHOUT* an active Chrome process holding references to the profile resources. If GCF is rendering a page when the cache is cleared, history *WILL NOT* be deleted on the GCF side, however GCF will continue to operate and IE will remove all other history artifacts as usual. IE 8: GCF cache is cleared in alignment with the options specified by the user. Clearing Temporary Internet Files may destroy the profile entirely, and so we need to consider not moving the GCF profile on IE 8. "InPrivate Filtering": IE 8 (only): more testing required. "InPrivate Browsing": IE 8 (only): pages rendered in GCF *after* entering InPrivate mode are not persisted to disk (use an incognito wrapper on the specified profile). Currently displayed pages are not effected by the switch, although refreshing them will invoke the new behavior. Generally speaking, BHO's are disabled by IE 8 while in InPrivate mode, so entering this state is wonky to begin with but we handle it as well as can be expected. BUG=22846 TEST=On IE 8, clear the cache entirely, note GCF entries in DbgView (better tests coming) Review URL: http://codereview.chromium.org/858003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42684 0039d316-1c4b-4281-b951-d872f2087c98
* Fix #1 for multiple request issue (both POST and GET) after activating the ↵tommi@chromium.org2010-03-121-31/+10
| | | | | | | | | | | | | | | | | | | | | onhttpequiv approach. There's a ton going on here. Brief summary: I'm introducing a caching layer for top level page requests that we then use again when switching the document from mshtml to cf. Also in this change list: * Removing the previous way of shifting the document moniker over to the worker thread when a new chrome document is created. Instead we use a request cache object. * Refactoring the part of the Bho class that offered access to it via TLS. This was needed for better testability but also makes (imho) the separation clearer and will possibly help in the future if we don't have a Bho object. * Added a bit of logging that I'd prefer to keep in there until we're confident enough with onhttpequiv. * Enabling two previously disabled tests (the ones I added for multiple requests) * Adding several more unit tests for the new code. Review URL: http://codereview.chromium.org/668187 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@41495 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting due to two broken tests: FullTabModeIE_SubIFram and ↵ericu@google.com2010-03-121-23/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | FullTabModeIE_UnloadEventTest. Revert 41463 - When ChromeFrame switches to IE on receiving the OnHttpEquiv notification indicating the presence of a meta tag indicating that the page is to be rendered in Chrome, we check if the notification is received for a site rendered in an IFrame to ensure that we don't switch in this case. This code is not reliable and we end up assuming that a top level navigation is actually an embedded frame. To work around this we now maintain a pending navigation count in BeforeNavigate2, which is decremented in NavigateComplete2 and NavigateError. We perform the check for an embedded document only if the pending navigation count is greater than 1. This fixes http://code.google.com/p/chromium/issues/detail?id=36825 The other change made is to add a delay of 100ms in SendString between each character to better reflect actual timing for real user input. Bug=36825 Review URL: http://codereview.chromium.org/837008 TBR=ananta@chromium.org Review URL: http://codereview.chromium.org/877009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@41477 0039d316-1c4b-4281-b951-d872f2087c98
* When ChromeFrame switches to IE on receiving the OnHttpEquiv notification ↵ananta@chromium.org2010-03-121-0/+23
| | | | | | | | | | | | | | | | | | | | | | | indicating the presence of a meta tag indicating that the page is to be rendered in Chrome, we check if the notification is received for a site rendered in an IFrame to ensure that we don't switch in this case. This code is not reliable and we end up assuming that a top level navigation is actually an embedded frame. To work around this we now maintain a pending navigation count in BeforeNavigate2, which is decremented in NavigateComplete2 and NavigateError. We perform the check for an embedded document only if the pending navigation count is greater than 1. This fixes http://code.google.com/p/chromium/issues/detail?id=36825 The other change made is to add a delay of 100ms in SendString between each character to better reflect actual timing for real user input. Bug=36825 Review URL: http://codereview.chromium.org/837008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@41463 0039d316-1c4b-4281-b951-d872f2087c98
* Fix for referrer flakyness. There were two problems:tommi@chromium.org2010-02-181-0/+7
| | | | | | | | | | | | | | | Grabbing the referrer header when the request is made and not in BeforeNavigate2. The request headers aren't always available in BeforeNavigate2. Mshtml provides these headers in IHttpNegotiate::BeginningTransaction, which is where we now grab them. There was a race in chrome_frame_automation.cc where we use std::string to store the referrer url and then access that string from different threads. This was causing the referrer URL to be missing at some times and at other times be sent over to chrome as bad string (e.g. containing embedded nulls) and subsequently be deemed an invalid URL and dropped. TEST=Fixes referrer header flakyness. BUG=34812 Review URL: http://codereview.chromium.org/646013 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@39383 0039d316-1c4b-4281-b951-d872f2087c98
* Enable onhttpequiv again. The difference this time around is that wetommi@chromium.org2010-02-051-4/+6
| | | | | | | | | | | | | perform the switch in onhttpequiv when done==false. Also, we don't rely on having access to the already existing moniker but instead create our own and DCHECK that it is IsRunning() (see comments). TEST=The double loading effect we were seeing before should be gone. BUG=33332 Review URL: http://codereview.chromium.org/576017 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@38232 0039d316-1c4b-4281-b951-d872f2087c98
* Enable optinurls regardless of PatchHelper::state().tommi@chromium.org2010-02-021-0/+2
| | | | | | | | | | | Also refactored the OptinUrls code into a separate function. TEST=The OptinUrls feature should work. BUG=none Review URL: http://codereview.chromium.org/561002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@37796 0039d316-1c4b-4281-b951-d872f2087c98
* Implement OptInUrls using the same mechanism we use in the onhttpequiv ↵tommi@chromium.org2010-01-221-1/+1
| | | | | | | | | | | | | notification. A noteworthy change here is that OptInUrls doesn't rely on cf: anymore. TEST=The OptInUrls registry key should start working properly again. BUG=32660 Review URL: http://codereview.chromium.org/549129 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@36874 0039d316-1c4b-4281-b951-d872f2087c98
* If we navigate to a URL which has an anchor in IE, which eventually ends up ↵ananta@chromium.org2010-01-221-1/+6
| | | | | | | | | | | | | | | | | | | | | in ChromeFrame, the actual URL queried from the moniker passed in to our implementation of IPersistStream::Load does not have the anchor. It looks like there are some private interfaces exposed by MSHTML and invoked by IEFrame to pass this information over. Our fix is to save away the url received in our Bho BeforeNavigate2 notification and use this URL if available before querying the moniker for the URL. This needs to be done in IPersistStream::Load and in the OnHttpEquiv patch when we initiate a navigation to the actual URL using the moniker. Fixes bug http://code.google.com/p/chromium/issues/detail?id=27270 Bug=27270 Test=Covered by unit test. Review URL: http://codereview.chromium.org/542096 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@36814 0039d316-1c4b-4281-b951-d872f2087c98
* Some Chrome Frame cleanup:robertshield@chromium.org2010-01-051-3/+0
| | | | | | | | | | | | | | | | | | 1) Rearrange the chrome_frame.gyp file to: a) Split out most of CF into a static lib to make writing unit tests easier (not having to re-include source files). b) Remove most of the un-needed xulrunner-sdk includes. 2) Move all OBJECT_ENTRY_AUTO macros to chrome_tab.cc since they don't work without extra work when residing in a lib. 3) Rename npchrome_tab.dll to npchrome_frame.dll. BUG=none TEST=none Review URL: http://codereview.chromium.org/523040 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35543 0039d316-1c4b-4281-b951-d872f2087c98
* Use the OnHttpEquiv notification to switch to CF when the http-equiv meta ↵tommi@chromium.org2009-12-111-4/+1
| | | | | | | | | | | | | | | | tag is detected. This implementation is still behind the registry switch (set PatchProtocols to 0 in the registry). I will switch over to it wholesale in a separate patch. We use the same mechanism for re-initiating the navigation we use to transfer downloads over to the host, so I moved the common code to utils.cc and added NavigateBrowserToMoniker. When we see a browser instance attempting to load a CF document, we raise a TLS flag that we catch in HttpNegotiatePatch::ReportProgress when the mime type is being reported. This is the same place where we examine http headers and report the mime type. BUG=n/a TEST=Set PatchProtocols (REG_DWORD) to 0 in the CF HKCU config key and make sure we detect and handle the meta tag as well or better than before. Review URL: http://codereview.chromium.org/489004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@34366 0039d316-1c4b-4281-b951-d872f2087c98
* Fix a race condition in InitializeAndPatchProtocolsIfNeeded as discovered by ↵tommi@chromium.org2009-11-131-1/+4
| | | | | | | | | | | MAD. TEST=Should fix the issue MAD saw when starting up and tearing down the host browser in quick succession. Please see bug description. BUG=27641 Review URL: http://codereview.chromium.org/387049 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31935 0039d316-1c4b-4281-b951-d872f2087c98
* When Chrome hands off a URL to be opened by the external host by the ↵ananta@chromium.org2009-10-191-0/+13
| | | | | | | | | | | | | | | | | | | | | | | ViewHostMsg_OpenURL IPC, it needs to pass the referrer as well. The Chrome fixes in this CL are mostly related to passing the HTTP referer off to the browser and from there to the ExternalTabContainer to ChromeFrame and back. The ChromeFrame changes are basically around the same lines with one exception. When we handle the AutomationMsg_OpenURL IPC in the activex and the active document we pass the referer if applicable to the WebBrowser2::Navigate2 interface, which is then read by the BHO in BeforeNavigate2. We then save away an AddRef'ed BHO pointer in TLS which is then referenced by the Active document for reading the referer and passing it off to Chrome in the NavigateInExternalTab message. Added a unit test in ChromeFrame which tests this case. This fixes http://code.google.com/p/chromium/issues/detail?id=22994 Bug=22994 Review URL: http://codereview.chromium.org/274071 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@29420 0039d316-1c4b-4281-b951-d872f2087c98
* Initial import of the Chrome Frame codebase. Integration in chrome.gyp ↵slightlyoff@chromium.org2009-09-241-0/+102
coming in a separate CL. BUG=None TEST=None Review URL: http://codereview.chromium.org/218019 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@27042 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-01-17 22:10:41 +0000