| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
that will fail for a day or two while we adapt.
TEST=Run all unit tests.
BUG=none
Review URL: http://codereview.chromium.org/552038
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@36507 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
tests on the builder.
TBR=robertshield
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@36010 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
| |
were hitting on the builder.
R=ananta
BUG=none
TEST=Run all unit tests. This is a second attempt to switch to onhttpequiv.
Review URL: http://codereview.chromium.org/543017
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@36009 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
TBR=tommi
Review URL: http://codereview.chromium.org/527020
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35724 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
TEST=Run all unit tests.
BUG=none
Review URL: http://codereview.chromium.org/519070
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35705 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
out to wininet like about:blank.
Altering constant name pulled in from latest platform SDK to avoid naming conflicts for those with said SDK.
Add slightly more logging to error messages.
BUG=DCHECK hit when loading about:blank.
TEST=Load about:blank in a debug build and no DCHECK is seen.
Review URL: http://codereview.chromium.org/465030
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33706 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
Chrome Frame to display chrome-extension URLs when running in privilegedmode.BUG=noneTEST=see unit tests
Review URL: http://codereview.chromium.org/246050
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@27724 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ChromeFrame VTable patches the IInternetProtocol interface for the CLSID_HttpProtocol
and CLSID_HttpSProtocol handlers. However we were using the same VTable information to patch both
the handlers essentially overwriting the first one. While this all worked purely by chance, it
exposed a bug in IE8 where every new tab initially goes into a new process and if the chromeframe
is unloaded we would leave behind an IInternetProtocol interface in urlmon patched, which would
crash when dereferenced.
Added a check in the VTable patching code for this case.
This fixes bug http://code.google.com/p/chromium/issues/detail?id=22768
Bug=22768
Review URL: http://codereview.chromium.org/244002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@27191 0039d316-1c4b-4281-b951-d872f2087c98
|
|
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
|