| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
IInternerProtocolSink::ReportProgress
implementation as this causes the chrome frame tests to break.
TBR=stoyan
Review URL: http://codereview.chromium.org/515022
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35244 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
type in our
IInternetProtocolSink::ReportProgress implementation. To determine the renderer type we
try to read the data from the IInternetProtocol interface which in turn tries to determine
the renderer type.
Fix is to check if we are in the context of determining the renderer and bail.
TBR=stoyan
Bug=31031
Review URL: http://codereview.chromium.org/518012
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35234 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
installed on the machine.
Based on my debugging it looks like AdBlock gets confused because we report the mime type initally as
text/html and then swich to application/chromepage.
Fix is to attempt to determine the mime type in our IInternetProtocolSink::ReportProgress implementation.
If we fail we continue to determine the mime type in IInternetProtocolSink::ReportData.
Added a helper function CheckAndReportChromeMimeTypeForRequest which is invoked from both places.
Fixes http://code.google.com/p/chromium/issues/detail?id=31031
Bug=31031
Review URL: http://codereview.chromium.org/501181
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35227 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
issue where a page that uses CF would be loaded in an IFRAME on Google Images.Instead of attempting to load CF (not supported), we now defer to the host browser. Previously a blank page was displayed.TEST=Run new unit tests: FullTabModeIE_SubIFrame and FullTabModeIE_SubFrameBUG=22989
Review URL: http://codereview.chromium.org/343086
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@30782 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|