| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
TEST=n/a
BUG=none
Review URL: http://codereview.chromium.org/1745007
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@45391 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/1650015
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@44991 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
switch to ChromeFrame, even when they don't
specify the meta tag or the HTTP header indicating the same.
Fixes bug http://code.google.com/p/chromium/issues/list?cursor=40124
Bug=40124
Review URL: http://codereview.chromium.org/1623001
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@43640 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the browser is tagged for CF navigation.
I found that if I load a CF page, then go to the address bar and press enter, we will actually get both OnHttpEquiv(done==false) and then followed by OnHttpEquiv(done==TRUE) even though we kicked off a new navigation in between. When this happened we would clear the cache in OnHttpEquiv(done==true) and subsequently we'd have to go to the network to fetch the content once CF is instantiated.
TEST=See description.
BUG=none
Review URL: http://codereview.chromium.org/1330001
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42675 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
TBR=amit
BUG=none
TEST=This enables PatchProtocols=2 by default.
Review URL: http://codereview.chromium.org/1171001
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42294 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes crashes due to NavigationManager instance being NULL.
TBR=tommi
BUG=38602,38603
Review URL: http://codereview.chromium.org/1100006
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42083 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
Attempting another approach to detect the dummy IWebBrowser2 iframe instances which mshtml creates for top level
navigations which results in the IE to Chrome switch not working reliably.
The location for these dummy browsers is set to about:blank. We now check for the same and ignore these.
I have added comments in the code indicating why we are doing this and the cases where it could break.
It should be fine for most common cases as this code is only hit when the page has a meta tag. Will revisit
this.
This fixes http://code.google.com/p/chromium/issues/detail?id=36825
Bug=36825
Test=Covered by unit test.
Review URL: http://codereview.chromium.org/911003
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@41645 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
because the VARIANT representing
the URL has a NULL bstrVal.
Fix is to check for the same.
Fixes bug http://code.google.com/p/chromium/issues/detail?id=37872
Bug=37872
Review URL: http://codereview.chromium.org/822005
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@41208 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
TBR=amit
TEST=fixes one of the top crashes in the lastest release.
BUG=36985
Review URL: http://codereview.chromium.org/661256
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@40234 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
TEST=Make sure unit tests still pass.
BUG=33332
Review URL: http://codereview.chromium.org/555178
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@37584 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
TEST=This avoids a DCHECK that could happen when viewing the source of an html page.
BUG=none
TBR=robertshield
Review URL: http://codereview.chromium.org/553073
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@37044 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
After reissuing a cf navigation we now remove the previous entry from the travellog to preserve the correct navigation history.
Also updating the BackForward unit tests to expect two pairs of BeforeNavigate/NavigateComplete notification when we transition from IE to CF.
TEST=Run *BackForward* unit tests
BUG=32550
Review URL: http://codereview.chromium.org/549092
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@36594 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
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
|