summaryrefslogtreecommitdiffstats
path: root/chrome_frame/utils.h
Commit message (Collapse)AuthorAgeFilesLines
* Export the new sessionid property of Chrome Frame form the NPAPI interface.rogerta@chromium.org2010-11-241-0/+1
| | | | | | | | | BUG=0 TEST=see included unit test Review URL: http://codereview.chromium.org/5331003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67311 0039d316-1c4b-4281-b951-d872f2087c98
* Fix a bug where in having ChromeFrame installed on the machine would cause a ↵ananta@chromium.org2010-11-011-21/+0
| | | | | | | | | | | | | | | | | | | | | | | | non chrome frame email site to automatically logout after logging in. ChromeFrame appends the chromeframe string to the user agent to outgoing requests initiated from IE. However this was only done in the protocol sink patch for top level requests. Sub requests would carry the IE user agent which in this case would cause the web server to get confused and drop the connection. Fix is to resurrent the IHttpNegotiate vtable patch for the protocol patch as well. Removed the code which read the patch method from the registry and turned on the moniker or the httpequiv patch. It is unlikely that we will need this in the future. Cleaned up the http negotiate patch by removing references to the navigation manager and the ReportProgress patch which is not needed anymore. Fixes bug http://code.google.com/p/chromium/issues/detail?id=60745 Bug=60745 Review URL: http://codereview.chromium.org/4247001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@64688 0039d316-1c4b-4281-b951-d872f2087c98
* Modify the parsing of X-UA-COMPATIBLE header (and meta tag) to allow comma ↵erikwright@chromium.org2010-10-261-4/+7
| | | | | | | | | | or semi-colon as delimiter for backwards compatibility. BUG=52601 TEST=chrome_frame_unittests / UtilTests.XUaCompatibleDirectiveTest Review URL: http://codereview.chromium.org/4103004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@63937 0039d316-1c4b-4281-b951-d872f2087c98
* Enable developers to conditionally activate Chrome Frame, depending on the ↵erikwright@chromium.org2010-10-251-7/+39
| | | | | | | | | | version of the host IE browser. BUG=52601 TEST=[chrome_frame_unittests / UtilTests.XUaCompatibleDirectiveTest], [chrome_frame_tests / HeaderTest.*] Review URL: http://codereview.chromium.org/3978001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@63728 0039d316-1c4b-4281-b951-d872f2087c98
* Convert LOG(INFO) to VLOG(1) - chrome_frame/.pkasting@chromium.org2010-10-191-2/+2
| | | | | | | | | | Plus a couple misc. cleanups. BUG=none TEST=none Review URL: http://codereview.chromium.org/3850002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@63095 0039d316-1c4b-4281-b951-d872f2087c98
* Move Stats, histograms, and field trial into a metrics subdirectory of base andbrettw@chromium.org2010-10-141-3/+3
| | | | | | | | | put them in the base namespace. TEST=it compiles BUG=none git-svn-id: svn://svn.chromium.org/chrome/trunk/src@62510 0039d316-1c4b-4281-b951-d872f2087c98
* Policy support for being able to specify a list of content types that Chrome ↵tommi@chromium.org2010-10-041-0/+5
| | | | | | | | | | | Frame should handle. TEST=This adds a new policy list for Chrome Frame, "ChromeFrameContentTypes", which can be used to specify a list of content types that should always be rendered in Chrome Frame. BUG=56543 Review URL: http://codereview.chromium.org/3611002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@61432 0039d316-1c4b-4281-b951-d872f2087c98
* Committing http://codereview.chromium.org/3420004/show for grt@robertshield@chromium.org2010-09-221-1/+33
| | | | | | | | | | | | | | | | Original description: - added detection of IE9 for ChromeFrame.IEVersion metric - replaced ChromeFrame.FullTabLaunchType metric with ChromeFrame.LaunchType metric, which logs more info regarding how it came to be that GCF rendered a page (but only for the CTransaction patch) BUG=43885 TEST=none Review URL: http://codereview.chromium.org/3443017 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@60188 0039d316-1c4b-4281-b951-d872f2087c98
* Remove code that enables renderer accessibility based on the ↵ctguil@chromium.org2010-09-181-0/+5
| | | | | | | | | | | | | SPI_GETSCREENREADER parameter. Update chrome frame so that its test automation can still use renderer accessibility. BUG=55902 TEST=none Review URL: http://codereview.chromium.org/3383010 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@59899 0039d316-1c4b-4281-b951-d872f2087c98
* Added full support for invoking before unload and unload handlers on ↵ananta@chromium.org2010-09-171-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | ChromeFrame rendered pages. This allows a webpage to put up a confirmation dialog in its beforeunload handler and potentially cancel the operation. We only support invoking unload handlers on the page for IE full tab mode. To achieve this the active document handles the OLECMDID_ONUNLOAD exec command which is passed by the DOCHOST to the object which allows us to potentially cancel the operation. Thanks to Stoyan for his help in authoring parts of this CL. The AutomationMsg_RunUnloadHandlers message which is used only by ChromeFrame is now a sync message which returns back a bool indicating whether the unload operation can be continued or not. The ExternalTabContainer now implements the BeforeUnloadFired method in the TabContentsDelegate and aborts the unload operation if the user chose to not proceed with the unload. Fixes bug http://code.google.com/p/chromium/issues/detail?id=33200 Bug=33200 Test=Covered by existing unload event test. Will add a test which validates whether a page can cancel the unload operation in a subsequent CL. Review URL: http://codereview.chromium.org/3450014 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@59854 0039d316-1c4b-4281-b951-d872f2087c98
* Change correcting the profile used when performing top-level navigations of ↵twiz@google.com2010-09-081-0/+5
| | | | | | | | | | | | | the host browser with a ChromeFrame instance. If a ChromeFrame instance was loaded with a given profile, the bho used to always forward top-level navigation requests to a CF full-tab instance using the default (iexplore) profile. This caused problems with the automation channel, and the navigation would not complete. I also cleaned up the gcf and host networking registry keys used by Chrome-Frame so that ActiveX instances will also respect their values. TEST=None BUG=None Review URL: http://codereview.chromium.org/3295019 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@58884 0039d316-1c4b-4281-b951-d872f2087c98
* Correct a problem whereby the prefetching experiment would never be ↵robertshield@chromium.org2010-09-031-0/+3
| | | | | | | | scheduled for updates. Review URL: http://codereview.chromium.org/3362001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@58440 0039d316-1c4b-4281-b951-d872f2087c98
* Pin the DLL if we make any patches instead of doing it from the Bho that ↵tommi@chromium.org2010-09-021-0/+4
| | | | | | | | | | | does not apply the patches itself. TEST=There should be no changes but we were seeing some potential problems in house with other proprietary browser extensions. BUG=none Review URL: http://codereview.chromium.org/3359001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@58350 0039d316-1c4b-4281-b951-d872f2087c98
* When GCF is the default renderer, use Chrome's User-agent header instead of ↵tommi@chromium.org2010-08-311-7/+12
| | | | | | | | | | | IE's. TEST=Set IsDefaultRenderer to 1 (REG_DWORD) under the ChromeFrame registry key. Check if the User agent header in requests is the Chrome user agent. Then set the value to 0 and make sure the regular user-agent header is there. BUG=50788 Review URL: http://codereview.chromium.org/3130016 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@57991 0039d316-1c4b-4281-b951-d872f2087c98
* FBTF: Remove unneeded headers from base/ (part 6)thestig@chromium.org2010-08-191-2/+3
| | | | | | | | BUG=none TEST=none Review URL: http://codereview.chromium.org/3093013 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@56641 0039d316-1c4b-4281-b951-d872f2087c98
* Restrict unsafe URLs in Chrome Frameamit@chromium.org2010-08-131-7/+12
| | | | | | | | | | | | | | | | | | | | | | | | Further tighten down what URLs can be loaded in Chrome Frame. Based on the feedback from the security review and code inspection, restrict about: scheme only to about:blank and about:version by default. Factor out logic blocking logic including for URL zone checking so that all ActiveX, ActiveDoc and NPAPI will follow the same path. As a result we now block restricted URL zones in NPAPI instance as well. Another side effect of this refactoring is that the registry flag, EnableGcfProtocol, is replaced by AllowUnsafeURLs. If If this flag is set, then all the security related checking is turned off. BUG=50741 TEST=By default gcf: works only for about:blank, about:version and view-source of http and https. Setting AllowUnsafeURLs to a non zero value should allow any URL be loaded via gcf: Review URL: http://codereview.chromium.org/3159006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@56096 0039d316-1c4b-4281-b951-d872f2087c98
* Ensure that window.open requests issued by ChromeFrame carry the correct ↵ananta@chromium.org2010-07-281-8/+54
| | | | | | | | | | | | | | | | | | | | | cookies in the outgoing HTTP requests. To achieve this we no longer issue navigations with the gcf:attach* prefix. We now issue a navigation to the current page URL with the attach external tab suffix, which indicates that the page is forced into ChromeFrame without making an actual HTTP request. This ensures that the new IE8 process has access to all HTTP cookies. We need to patch IInternetProtocol::LockRequest and UnlockRequest to not call the underlying implementations for our dummy request as this crashes in IE8 in the prebinding code path. Fixes bug http://b/issue?id=2277519 Added tests for the CanNavigateFullTabMode helper function. Bug=2277519 Review URL: http://codereview.chromium.org/3051018 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@54019 0039d316-1c4b-4281-b951-d872f2087c98
* Second attempt at trying to land buggy bho avoidance: ↵tommi@chromium.org2010-07-211-0/+1
| | | | | | | | | | | | | | | | | | 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-1/+0
| | | | | | | | | | | | | | | | | | 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-0/+1
| | | | | | | | | | | | | | | | 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
* Not firing DocumentComplete in the presence of buggy BHOs.tommi@chromium.org2010-07-161-0/+7
| | | | | | | | | TEST=should be no functional change except if there are buggy BHOs that we know of loaded in IE. BUG=44463 Review URL: http://codereview.chromium.org/2906011 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@52668 0039d316-1c4b-4281-b951-d872f2087c98
* window.open calls issued by pages within ChromeFrame would not honor the ↵ananta@chromium.org2010-06-171-1/+10
| | | | | | | | | | | | | | | | | | | | | | | suggested dimensions and would end up opening a default top level browser window in IE. ChromeFrame does receive the dimensions from the external tab container when it is notified about a popup being opened. Fix is to honor these dimensions by passing them off in the specially crafted url containing other arguments. Fixes bug http://code.google.com/p/chromium/issues/detail?id=42250 This fix is currently implemented for IE full tab mode only. Bug=42250 Test=Covered by augmenting the existing window open test to also validate the window size. Added a new unit test to test the ParseAttachExternalTabUrl helper function. Review URL: http://codereview.chromium.org/2867007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@50064 0039d316-1c4b-4281-b951-d872f2087c98
* Add support for uploading UMA metrics data from ChromeFrame. Added support ↵ananta@chromium.org2010-06-111-0/+8
| | | | | | | | | | | | | | | | for tracking chrome frame crash metrics via 2 new counters which track successful navigations and crashes. These counters are persisted in the registry under HKCU\Software\Google\ChromeFrameMetrics. Any other histogram data like AutomationServer launch time, IE versions etc are simply dropped if IE is shutdown before they are sent out. The metrics data is uploaded on similar lines as Chrome. Bug=46057 Review URL: http://codereview.chromium.org/2714003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@49493 0039d316-1c4b-4281-b951-d872f2087c98
* A new way of hooking internet protocols.stoyan@chromium.org2010-06-091-1/+6
| | | | | | | | TEST=chrome frame tests Review URL: http://codereview.chromium.org/2620001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@49265 0039d316-1c4b-4281-b951-d872f2087c98
* Candidate fix for bug 44108. The FromBindContext function was inherently ↵tommi@chromium.org2010-05-141-0/+12
| | | | | | | | | | | | | 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
* Only switch to cf for text/html. With opt-in URLs we could mark a URL to be ↵tommi@chromium.org2010-04-211-5/+13
| | | | | | | | | | | loaded in CF regardless of the target mime type. If CF turns around and wants to download the target, we would hit an infinite loop. TEST=Verify that issue 40046 is resolved. OptIn urls should work with the moniker patch and downloads should not cause an infinite loop. BUG=40046 Review URL: http://codereview.chromium.org/1715004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@45226 0039d316-1c4b-4281-b951-d872f2087c98
* In ChromeFrame with the moniker patch enabled we should not process optin ↵ananta@chromium.org2010-04-201-0/+7
| | | | | | | | | | | | urls in the BHO. Fixes bug http://code.google.com/p/chromium/issues/detail?id=42155 Bug=42155 Review URL: http://codereview.chromium.org/1706003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@45117 0039d316-1c4b-4281-b951-d872f2087c98
* With the ChromeFrame IMoniker patch in the referrer would not propagate ↵ananta@chromium.org2010-04-161-0/+10
| | | | | | | | | | | | | | | | | | | | correctly to Chrome when we switch from IE to CF. In ChromeFrame the referrer is set in the navigation manager which receives this in the IHttpNegotiate::BeginningTransaction patch. When we switch from IE to cF via the moniker patch we receive two calls to BeginningTransaction, the first one with the referrer and the other one without the referrer for the same URL causing the referrer to be overwritten. Fix is to handle this case. The referrer is cleared in our BeforeNavigate notification. I also moved some functions to chrome frame utils as part of this CL. Fixes bug http://code.google.com/p/chromium/issues/detail?id=41680 Bug=41680 Review URL: http://codereview.chromium.org/1653006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@44733 0039d316-1c4b-4281-b951-d872f2087c98
* IE would not switch into ChromeFrame if the url being navigated to had an ↵ananta@chromium.org2010-04-131-0/+8
| | | | | | | | | | | | | | | | | | | | anchor. The IsTopLevelUrl function exposed by the navigation manager would compare the URL received in the BHO which has the anchor and the URL received from the anchor which does not have the anchor. As a result we would not wrap the bind status callback which caused this issue. The IsTopLevelUrl function now compares the URLs after stripping the anchor portion in the URL. Should fix bug http://code.google.com/p/chromium/issues/detail?id=38265. This only works if the moniker patch is enabled. Bug=38265 Test=Covered by unit test. Review URL: http://codereview.chromium.org/1559027 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@44309 0039d316-1c4b-4281-b951-d872f2087c98
* Switch renderer in Moniker patchamit@chromium.org2010-04-091-5/+1
| | | | | | | | | | Step one of the changes. Inspect data and cause a switch in the moniker patch. Review URL: http://codereview.chromium.org/1589013 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@44038 0039d316-1c4b-4281-b951-d872f2087c98
* Fixes GCF perf tests in prep for re-enabling them on the bots.slightlyoff@chromium.org2010-03-261-0/+5
| | | | | | | | | BUG=36734 TEST=build/run chrome_frame_perftests.exe, note that they all run now Review URL: http://codereview.chromium.org/1433002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42870 0039d316-1c4b-4281-b951-d872f2087c98
* 3rd try. *sigh*slightlyoff@chromium.org2010-03-261-0/+3
| | | | | | | | | | | | | 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-3/+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/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 for a race issue when chrome decides that a request needs to be ↵tommi@chromium.org2010-03-251-2/+10
| | | | | | | | | | | | | | downloaded by the host browser. Before the request could under some circumstances be terminated before we handed it over to the host for download. In such cases we would just drop the request and not download anything. TEST=Fixes flakyness of _some_ download scenarios. This is only a part of a fix needed for the related bug. BUG=36694 Review URL: http://codereview.chromium.org/1240004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42673 0039d316-1c4b-4281-b951-d872f2087c98
* Initial support for IE View->Privacy. To support this menu option the active ↵ananta@chromium.org2010-03-191-0/+8
| | | | | | | | | | | | | | | | | | | | | | | document now implements the Exec command for the CGID_ShellDocView group and command id 75. We invoke the DoPrivacyDlg function exported by shdocvw and pass in our implementation of the IEnumPrivacyServices interface. The actual privacy data is gathered and maintained by the UrlmonUrlRequestManager. If we detect a privacy violation we notify the shell browser via the ITridentService2::FirePrivacyImpactedStateChange function which ensures that IE displays the privacy icon. Thanks to stoyan for his help in getting this done. I will add tests in a followup CL. Fixes bug http://code.google.com/p/chromium/issues/detail?id=25479 Bug=25479 Review URL: http://codereview.chromium.org/1127003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42113 0039d316-1c4b-4281-b951-d872f2087c98
* Fix #1 for multiple request issue (both POST and GET) after activating the ↵tommi@chromium.org2010-03-121-0/+18
| | | | | | | | | | | | | | | | | | | | | 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
* Fix a ChromeFrame crash which occured in the Histogram code while adding a ↵ananta@chromium.org2010-03-051-0/+18
| | | | | | | | | | | | | | | | | | histogram. The histogram macros basically instantiate a static Histogram instance which is then tracked. The static initialization is not thread safe and thus could cause a crash if there is a race between multiple threads trying to access the object at the same time. Fix based on a discussion with Jim is to add thread safe versions of the macros we use for ChromeFrame. Fixes bug http://code.google.com/p/chromium/issues/detail?id=37470 Bug=37470 Review URL: http://codereview.chromium.org/669135 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@40757 0039d316-1c4b-4281-b951-d872f2087c98
* Adding a little utility function to make logging guids easiertommi@chromium.org2010-03-011-0/+2
| | | | | | | | | | | and a dlog to see when we decide that a request is a subframe request. TEST=Unit test is provided. BUG=none Review URL: http://codereview.chromium.org/660289 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@40288 0039d316-1c4b-4281-b951-d872f2087c98
* First batch of context menu testsamit@chromium.org2010-02-121-0/+4
| | | | | | | | | | | | | | | | Refactored various methods to send keyboard and mouse input. Fixed the context menu focus issue on IE7. Improved existing tests to make them less flaky and added 3 new tests for context menu items. BUG=34673 TEST=new tests added Review URL: http://codereview.chromium.org/604014 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@38905 0039d316-1c4b-4281-b951-d872f2087c98
* Remove cf: protocolamit@chromium.org2010-02-031-2/+2
| | | | | | | | | | | | | | | | | | | | Well, almost. cf: is now changed to gcf: protocol. gcf: protocol now is supported only for the following cases: 1. gcf:attach_external_tabXXX urls. These are URLs used internally by Chrome Frame to implement window.open 2. gcf:about:xxx 3. gcf:view-source:xxx 4 For any other URLs ONLY if it is enabled by setting a registry value 'EnableGCFProtocol' to 1 in HKCU\Software\Google\ChromeFrame BUG=22721,23006,23175,29350 TEST=changed existing cf: tests to new gcf: tests, added a new test for cf:view-source Review URL: http://codereview.chromium.org/562008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@37981 0039d316-1c4b-4281-b951-d872f2087c98
* TEST=new tests added.stoyan@chromium.org2010-02-011-0/+20
| | | | | | Review URL: http://codereview.chromium.org/545093 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@37728 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/+11
| | | | | | | | | | | | | | | | | | | | | 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
* Updates for onhttpequiv. Preserving the referrer header, zapping the ↵tommi@chromium.org2010-01-161-1/+2
| | | | | | | | | | | | | currently loading document to prevent small documents from executing code. I'm not enabling httpequiv just yet as there are a couple of things I'm working on related to tests that will break once I make the switch. TEST=There should be no change since the code isn't still active but run all tests just to be safe. BUG=none Review URL: http://codereview.chromium.org/545096 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@36436 0039d316-1c4b-4281-b951-d872f2087c98
* Speculative fix for a ChromeFrame crash in IE full tab mode. The crash ↵ananta@chromium.org2009-12-281-2/+5
| | | | | | | | | | | | | | | | | | occurs while processing an accelerator message and based on the callstack it looks like QueryService call for the SID_STopLevelBrowser interface returns S_OK with a NULL interface pointer. Added checks in the DoQueryService helper function to return a failure if the QueryService call returns a NULL service pointer. Fixes http://code.google.com/p/chromium/issues/detail?id=25457 Bug=25457 Review URL: http://codereview.chromium.org/523008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35315 0039d316-1c4b-4281-b951-d872f2087c98
* Handle right-click->"Save Link As" in the host browser.tommi@chromium.org2009-12-161-0/+3
| | | | | | | | | TEST=Right click on a link in CF and select "save link as". You should immediately get the host browser's download UI. Before there could be a significant wait before this happened. BUG=23561 Review URL: http://codereview.chromium.org/506042 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@34783 0039d316-1c4b-4281-b951-d872f2087c98
* Use the OnHttpEquiv notification to switch to CF when the http-equiv meta ↵tommi@chromium.org2009-12-111-1/+15
| | | | | | | | | | | | | | | | 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
* Added support for running reliability tests for ChromeFrame on similar lines ↵ananta@chromium.org2009-12-091-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | as Chrome. We only run these tests for IE at this point. The reliability test code for Chrome has been copied and modified accordingly. Other related changes in this CL include the following:- 1. If ChromeFrame is running in headless mode determined by a registry value in HKCU\Software\Google\ChromeFrame we initialize ChromeFrame crash reporting and connect to the Chrome crash server. This would enable us to gather crash dumps from the reliability test runs and report the same. 2. The LowIntegrity fixes for the WebBrowser which Stoyan had done a while back are only needed for IE7 on Vista. For this CL though we just do the requisite hacks if the OS is Vista. For Windows7 the returned IWebBrowser interface pointer works fine. 3. I moved the WebBrowserEventSink to chrome_frame_test_utils as this class is now shared. Fixes portions of http://code.google.com/p/chromium/issues/detail?id=29451 Bug=29451 Review URL: http://codereview.chromium.org/465074 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@34119 0039d316-1c4b-4281-b951-d872f2087c98
* Limit the X-UA-Compatible HTTP header-based altering of the mime type ↵robertshield@chromium.org2009-12-041-0/+11
| | | | | | | | | | | performed by Chrome Frame to top-level requests only in IE. BUG=having an iframe that requests a resource that includes the X-UA-Compatible header in the response will trigger CF taking over the page. TEST=BUG doesn't happen anymore. Review URL: http://codereview.chromium.org/465036 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33849 0039d316-1c4b-4281-b951-d872f2087c98
* Adding support for Chrome Frame to be loaded via the presence of an ↵robertshield@chromium.org2009-12-031-0/+5
| | | | | | | | | | | | | X-UA-Compatible HTTP header (in addition to the meta tag support). Also pins the CF module into the process such that it won't get unloaded. Doing this to work around how we can get unloaded without unpatching properly. BUG=22802 TEST=Navigate to a web site whose server sends the X-UA-Compatible: chrome=1 HTTP header and ensure that the page is loaded in CF. Review URL: http://codereview.chromium.org/465009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33629 0039d316-1c4b-4281-b951-d872f2087c98