summaryrefslogtreecommitdiffstats
path: root/chrome_frame/http_negotiate.h
Commit message (Collapse)AuthorAgeFilesLines
* Integrate the Ready Mode prompt with IE and Chrome Frame. In Ready Mode, ↵erikwright@chromium.org2011-01-121-2/+9
| | | | | | | | | | prompts are displayed when the user browses to GCF-enabled sites, allowing the user to permanently activate, permanently decline, or temporarily decline Chrome Frame. BUG=None TEST=chrome_frame_unittests --gtest_filter=Ready* && chrome_frame_unittests --gtest_filter=Infobar* && setup.exe --chrome-frame --ready-mode --multi-install --system--level --chrome Review URL: http://codereview.chromium.org/6040003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@71215 0039d316-1c4b-4281-b951-d872f2087c98
* Restore the IHttpNegotiate patch in ChromeFrame for IE9 which sends the ↵ananta@chromium.org2010-12-171-0/+47
| | | | | | | | | | | | | | | short UA string by default without the Post Platform values which we rely on. This reverts back to the old behavior for IE9 with the bug that certain top level requests like Refresh on a page rendered in IE will be sent out with the UA string without the chrome frame suffix. BUG=45087 TEST=Covered by old http negotiate unit test. Review URL: http://codereview.chromium.org/5957001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@69586 0039d316-1c4b-4281-b951-d872f2087c98
* Add the ChromeFrame UA in the post platform section in the IE user agent ↵ananta@chromium.org2010-12-161-47/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | string. To achieve this we need to add the desired value in the registry under the Internet Settings\User Agent\Post Platform key. We add this under the per user or per machine section in the registry depending on whether ChromeFrame is being installed in per user or per machine mode. This fixes the bug where certain top level requests in IE would not have the chrome frame UA appended to the IE UA. Removed the BeginningTransaction vtable patch code, which only existed to add chrome frame to the UA in outgoing requests. The limitation with registering the chrome frame UA in the registry is that it will be sent out even in the ChromeFrame BHO is disabled. Fixes bug http://code.google.com/p/chromium/issues/detail?id=45087 BUG=45087 TESt=Covered by new chrome frame test. Review URL: http://codereview.chromium.org/5831002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@69442 0039d316-1c4b-4281-b951-d872f2087c98
* Fix a bug where in having ChromeFrame installed on the machine would cause a ↵ananta@chromium.org2010-11-011-36/+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
* When GCF is the default renderer, use Chrome's User-agent header instead of ↵tommi@chromium.org2010-08-311-1/+6
| | | | | | | | | | | 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
* BUG=47879stoyan@chromium.org2010-07-171-0/+36
| | | | | | Review URL: http://codereview.chromium.org/2824057 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@52806 0039d316-1c4b-4281-b951-d872f2087c98
* In ChromeFrame in the IInternetProtocolRoot::ReportProgress patch use the ↵ananta@chromium.org2010-05-211-4/+0
| | | | | | | | | | | | | | | | | | | exception barrier version which only reports crashes in ChromeFrame while calling the original function. We also use the other version of the ExceptionBarrier when we switch the mime type from text/html. This is to prevent the vectored exception handler from handling this exception and reporting a false positive if any stack based exception handler actually handles this exception. The other change is to remove the IHttpNegotiate::OnResponse patch as it did not do anything useful and some crashes were being reported while invoking the original function. Fixes bugs http://code.google.com/p/chromium/issues/detail?id=44767 and http://code.google.com/p/chromium/issues/detail?id=44765 Bug=44767,44765 Review URL: http://codereview.chromium.org/2078030 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@47957 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-0/+11
| | | | | | | | | | | 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
* Adding support for Chrome Frame to be loaded via the presence of an ↵robertshield@chromium.org2009-12-031-1/+26
| | | | | | | | | | | | | 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
* Add the chromeframe tag to the user agent header at runtime instead of ↵tommi@chromium.org2009-10-171-0/+47
statically in the registry.TEST=Try disabling GCF and see if the chromeframe tag in the user agent is still set. It should not be. Also make sure you don't have an older version installed... the chromeframe tag should not be in the registry - if it is, you've got an older version still registered. This should fix the issue with going to wave.google.com after disabling chrome frame and seeing the white page of death.R=amitBUG=22760 Review URL: http://codereview.chromium.org/259025 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@29370 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-01-13 21:33:12 +0000