summaryrefslogtreecommitdiffstats
path: root/chrome_frame/urlmon_moniker.h
Commit message (Collapse)AuthorAgeFilesLines
* FBTF: Remove unneeded headers from base/ (part 1)thestig@chromium.org2010-08-051-1/+0
| | | | | | | | BUG=none TEST=none Review URL: http://codereview.chromium.org/3071012 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@55034 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 44897 - Improved compatibility support for IE8.tommi@chromium.org2010-04-191-0/+2
| | | | | | | | | | | | | | | | | | | | 1) We no longer add a user agent to requests that do not already have one. This will result in the correct user agent header being applied but it will not have the chromeframe tag. Requests that will be affected include requests from other plugins and XHR but not top level requests. 2) Requests from Chrome Frame will always have the native user agent applied regardless of compatibility settings. This means that in IE8, you will always see CF requests with MSIE 8.0 even though the target site is otherwise configured to run in IE7 compatibility. TEST=Make sure all CF websites continue to work properly. Also, turn on IE7 compatibility mode for some websites (e.g. wave, vimeo) and check if the user agent sent to those sites contains "MSIE 7.0" for pages that are not rendered in CF. Pages rendered in CF should always have the IE8 header with the possible exception of the very first request if that request was issued by mshtml. BUG=28816 Review URL: http://codereview.chromium.org/1521037 TBR=tommi@chromium.org Review URL: http://codereview.chromium.org/1659008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@44919 0039d316-1c4b-4281-b951-d872f2087c98
* Improved compatibility support for IE8.tommi@chromium.org2010-04-181-2/+0
| | | | | | | | | | | | | | | | | 1) We no longer add a user agent to requests that do not already have one. This will result in the correct user agent header being applied but it will not have the chromeframe tag. Requests that will be affected include requests from other plugins and XHR but not top level requests. 2) Requests from Chrome Frame will always have the native user agent applied regardless of compatibility settings. This means that in IE8, you will always see CF requests with MSIE 8.0 even though the target site is otherwise configured to run in IE7 compatibility. TEST=Make sure all CF websites continue to work properly. Also, turn on IE7 compatibility mode for some websites (e.g. wave, vimeo) and check if the user agent sent to those sites contains "MSIE 7.0" for pages that are not rendered in CF. Pages rendered in CF should always have the IE8 header with the possible exception of the very first request if that request was issued by mshtml. BUG=28816 Review URL: http://codereview.chromium.org/1521037 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@44897 0039d316-1c4b-4281-b951-d872f2087c98
* With the ChromeFrame IMoniker patch in the referrer would not propagate ↵ananta@chromium.org2010-04-161-7/+0
| | | | | | | | | | | | | | | | | | | | 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
* Avoid a crash in ChromeFrame in the BindToStorage call initiated when our ↵ananta@chromium.org2010-04-151-5/+0
| | | | | | | | | | | | | | | | active document is loaded. The crash occurs while dereferencing a NULL delegate which is the case in the pending request object created by the active document to handle the initial load. Fix for this is to maintain a pending state in the request object. We ignore all OnProgress notifications in this state. When Chrome requests data for the top level url this state is cleared. Consolidated the number of bind context information structures into one which contains everything we need in ChromeFrame, i.e. to decide to switch to Chrome, indicating whether the request came from Chrome, etc. Review URL: http://codereview.chromium.org/1654012 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@44604 0039d316-1c4b-4281-b951-d872f2087c98
* Fix for remaining major issues with moniker patchamit@chromium.org2010-04-141-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes things so that they now work 'naturally', i.e switch to chrome frame looks just like switching to pdf. The same bind context and underlying network transaction objects are used and requests aren't sent multiple times. Finally the TestPostReissue test is happy! This patch fixes two issues with earlier scheme: Issue 1: data can be read only once from a given bind context. Mshtml looks at the mime type in the FORMATETC but never issues a read. So when it switches, the new active document can read from start. Since we are reading the data for switching, when we actually switch, we have to transfer over the data read so far to our UrlmonUrlRequest. Issue 2: The very first UrlmomUrlRequest has to start binding right away, in the context of BindToStorage or network transcations associated with the bind context are gone (due to OnStopBinding for BindToObject). TEST=covered by existing tests BUG=33332 Review URL: http://codereview.chromium.org/1508033 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@44427 0039d316-1c4b-4281-b951-d872f2087c98
* IE would not switch into ChromeFrame if the url being navigated to had an ↵ananta@chromium.org2010-04-131-17/+1
| | | | | | | | | | | | | | | | | | | | 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
* Further improvments in IE switchingamit@chromium.org2010-04-121-4/+2
| | | | | | | | | | | | | | | | Manually loading active document in IMoniker::BindToObject does not work in IE6. The binding is not initialized and directly calling BindToStorage on it just does not return the data. The solution is to register ActiveDoc's CLSID as handler for 'text/html' mime type in the bind context marked for switching. Urlmon will correctly instantiate it them BUG=none TEST=covered by existing tests. Review URL: http://codereview.chromium.org/1595021 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@44274 0039d316-1c4b-4281-b951-d872f2087c98
* Fix IE6 switching issuesananta@chromium.org2010-04-091-1/+2
| | | | | | | | | | | Fixes for issues with new moniker patch. BUG=none TEST=covered by existing tests Review URL: http://codereview.chromium.org/1625010 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@44160 0039d316-1c4b-4281-b951-d872f2087c98
* Switch renderer in Moniker patchamit@chromium.org2010-04-091-241/+20
| | | | | | | | | | 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
* IE6 would not switch to ChromeFrame if the url being navigated to contained ↵ananta@chromium.org2010-03-161-0/+14
| | | | | | | | | | | | | | | | | | | | | an anchor. This is presumably because from IE6's perspecive nothing changed. To workaround this issue, we stash the complete url away in the navigation manager and remove it from the URL being navigated to. When the Chrome active document loads we read the actual url from the navigation manager and initiate a navigation to this URL. There is one issue with this approach though. The actual URL in the address bar in IE6 does not contain the anchor tag. Will address that in a follow up CL. This fixes bug http://code.google.com/p/chromium/issues/detail?id=38265 Bug=38265 Test=Covered by existing ChromeFrame anchor URL navigation tests. Review URL: http://codereview.chromium.org/1022003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@41776 0039d316-1c4b-4281-b951-d872f2087c98
* Fix #1 for multiple request issue (both POST and GET) after activating the ↵tommi@chromium.org2010-03-121-0/+404
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
generated by cgit v1.1 at 2025-01-17 06:41:40 +0000