summaryrefslogtreecommitdiffstats
path: root/chrome_frame/chrome_frame_npapi.cc
Commit message (Collapse)AuthorAgeFilesLines
* Fix ChromeFrame Firefox unit test failures. The host network stack ↵ananta@chromium.org2010-02-021-2/+2
| | | | | | | | | | | | implementation for Firefox needs to ignore streams created as a result of the src attribute for the ChromeFrame plugin. Fixed the signatures of the stream handling functions to return NPError instead of bool as the semantics differ if we return true which equates to NPERR_USER_BREAK. Review URL: http://codereview.chromium.org/561005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@37765 0039d316-1c4b-4281-b951-d872f2087c98
* TEST=new tests added.stoyan@chromium.org2010-02-011-51/+24
| | | | | | Review URL: http://codereview.chromium.org/545093 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@37728 0039d316-1c4b-4281-b951-d872f2087c98
* Window.open calls issued by pages within ChromeFrame which use the ↵ananta@chromium.org2010-01-281-0/+1
| | | | | | | | | | | | | | | | | | | NEW_WINDOW/NEW_POPUP dispositions open up as regular Chrome windows, which results in them not using the host network stack, which means that HTTP sessions/cookies, etc established by the main page will not work for the popup. Fix is to ensure that these dispositions also get routed back to the host browser where a new tab would be created which would attach itself to the newly created ExternalTabContainer instance. Fixes bug http://code.google.com/p/chromium/issues/detail?id=33324 Bug=33324 Test=Covered by ChromeFrame unit test. Review URL: http://codereview.chromium.org/549183 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@37425 0039d316-1c4b-4281-b951-d872f2087c98
* Attempt 2 at landing this.ananta@chromium.org2010-01-081-150/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Deleting cookies by setting the expires attribute on them with an empty value would not work in ChromeFrame with the host network stack enabled. When we receive a response in the host browser (IE) we send over the response headers which include the Set-Cookie header and a list of cookies retreived via the InternetGetCookie API. We call this API to retrieve the persistent cookies and send them over to Chrome. However this API returns session cookies as well as persistent cookies. There is no documented way to return only persistent cookies from IE. As a result we would end up setting duplicate cookies in Chrome, which caused this issu.e. To workaround this issue when we receive the response in the url request automation job which handles ChromeFrame network requests, we strip out duplicate cookies sent via InternetGetCookie. When a script deletes a cookie we now handle it correctly in IE and set the data to an empty string. However this does not delete the cookie. When such cookies show up in Chrome, we strip them out as well. Fixes bug http://code.google.com/p/chromium/issues/detail?id=30786 The changes to chrome_frame_npapi.cc/.h are to move the NPAPI functions to the chrome_frame namespace as they conflict with similar functions in NACL. Added the DeleteCookie function to the CookieStore interface, which I think missed out by oversight. Bug=30786 Test=Covered by ChromeFrame unit tests. I also added a unit test to test the newly added URLRequestAutomationJob::IsCookiePresentInCookieHeader function TBR=amit Review URL: http://codereview.chromium.org/521072 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35778 0039d316-1c4b-4281-b951-d872f2087c98
* Reason:tyoshino@chromium.org2010-01-081-0/+150
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Linux Builder (ChromiumOS) failed. http://chrome-buildbot.corp.google.com:8010/builders/Linux%20Builder%20(ChromiumOS)/builds/2050/steps/compile/logs/stdio Please add changes to external_cookie_handler_unittest.cc no to break compilation and reland? ---- Revert 35769 - Deleting cookies by setting the expires attribute on them with an empty value would not work in ChromeFrame with the host network stack enabled. When we receive a response in the host browser (IE) we send over the response headers which include the SetCookie header and a list of cookies retreived via the InternetGetCookie API. We call this API to retrieve the persistent cookies and send them over to Chrome. However this API returns session cookies as well as persistent cookies. There is no documented way to return only persistent cookies from IE. As a result we would end up setting duplicate cookies in Chrome, which caused this issu.e. To workaround this issue when we receive the response in the url request automation job which handles ChromeFrame network requests, we strip out duplicate cookies sent via InternetGetCookie. When a script deletes a cookie we now handle it correctly in IE and set the data to an empty string. However this does not delete the cookie. When such cookies show up in Chrome, we strip them out as well. Fixes bug http://code.google.com/p/chromium/issues/detail?id=30786 The changes to chrome_frame_npapi.cc/.h are to move the NPAPI functions to the chrome_frame namespace as they conflict with similar functions in NACL. Added the DeleteCookie function to the CookieStore interface, which I think missed out by oversight. Bug=30786 Test=Covered by ChromeFrame unit tests. I also added a unit test to test the newly added URLRequestAutomationJob::IsCookiePresentInCookieHeader function Review URL: http://codereview.chromium.org/518054 TBR=ananta@chromium.org Review URL: http://codereview.chromium.org/517070 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35771 0039d316-1c4b-4281-b951-d872f2087c98
* Deleting cookies by setting the expires attribute on them with an empty ↵ananta@chromium.org2010-01-081-150/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | value would not work in ChromeFrame with the host network stack enabled. When we receive a response in the host browser (IE) we send over the response headers which include the Set-Cookie header and a list of cookies retreived via the InternetGetCookie API. We call this API to retrieve the persistent cookies and send them over to Chrome. However this API returns session cookies as well as persistent cookies. There is no documented way to return only persistent cookies from IE. As a result we would end up setting duplicate cookies in Chrome, which caused this issu.e. To workaround this issue when we receive the response in the url request automation job which handles ChromeFrame network requests, we strip out duplicate cookies sent via InternetGetCookie. When a script deletes a cookie we now handle it correctly in IE and set the data to an empty string. However this does not delete the cookie. When such cookies show up in Chrome, we strip them out as well. Fixes bug http://code.google.com/p/chromium/issues/detail?id=30786 The changes to chrome_frame_npapi.cc/.h are to move the NPAPI functions to the chrome_frame namespace as they conflict with similar functions in NACL. Added the DeleteCookie function to the CookieStore interface, which I think missed out by oversight. Bug=30786 Test=Covered by ChromeFrame unit tests. I also added a unit test to test the newly added URLRequestAutomationJob::IsCookiePresentInCookieHeader function Review URL: http://codereview.chromium.org/518054 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35769 0039d316-1c4b-4281-b951-d872f2087c98
* Handle right-click->"Save Link As" in the host browser.tommi@chromium.org2009-12-161-1/+2
| | | | | | | | | TEST=Right click on a link in CF and select "save link as". You should immediately get the host browser's download UI. Before there could be a significant wait before this happened. BUG=23561 Review URL: http://codereview.chromium.org/506042 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@34783 0039d316-1c4b-4281-b951-d872f2087c98
* Don't treat CF in privileged mode as an iframe for framebustingjoi@chromium.org2009-11-171-1/+1
| | | | | | | | | | | headers. BUG=none TEST=none Review URL: http://codereview.chromium.org/402013 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32183 0039d316-1c4b-4281-b951-d872f2087c98
* Allowing JS to set/reset extension automation, this makes for morejoi@chromium.org2009-11-081-0/+51
| | | | | | | | | | | | | | | flexible testing when you want to automate different sets of functions in different tests. Now instead of needing to destroy your CF and then create a new one with a different automation functions attribute, you can just call the function to reset on the existing one, then call it again to enable a different set. BUG=none TEST=none Review URL: http://codereview.chromium.org/375014 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31406 0039d316-1c4b-4281-b951-d872f2087c98
* Basic wiring to enable downloads for CF's host browser network stack. A ↵tommi@chromium.org2009-11-071-1/+1
| | | | | | | | notable change here is that url automation job id's no longer exist and instead a request id is used. There's a 1 to 1 relation between a job and a request so this is more convenient. Review URL: http://codereview.chromium.org/355036 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31363 0039d316-1c4b-4281-b951-d872f2087c98
* Enhance extension UI testing by enabling you to select which extensionjoi@chromium.org2009-10-231-0/+11
| | | | | | | | | | | | | | APIs to forward (and thus stub out in your test), while others will keep being fulfilled as per usual. This lets you build tests that stub out one piece of behavior while testing that some side effects of another API happen as expected. BUG=none TEST=Run ui_tests.exe Review URL: http://codereview.chromium.org/314015 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@29919 0039d316-1c4b-4281-b951-d872f2087c98
* Add bindings to chrome frame to call the new extension automation apis.rogerta@chromium.org2009-10-231-0/+85
| | | | | | | | | TEST=see unit tests BUG=0 Review URL: http://codereview.chromium.org/284017 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@29902 0039d316-1c4b-4281-b951-d872f2087c98
* When Chrome hands off a URL to be opened by the external host by the ↵ananta@chromium.org2009-10-191-2/+6
| | | | | | | | | | | | | | | | | | | | | | | 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
* Committing patch 256001 for Roger:http://codereview.chromium.org/256001Allow ↵tommi@chromium.org2009-10-011-3/+3
| | | | | | | | 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
* Initial import of the Chrome Frame codebase. Integration in chrome.gyp ↵slightlyoff@chromium.org2009-09-241-0/+1462
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