summaryrefslogtreecommitdiffstats
path: root/chrome/browser/automation
Commit message (Collapse)AuthorAgeFilesLines
* Remove the temporary scaffolding stubs.phajdan.jr@chromium.org2010-02-101-2/+41
| | | | | | | | | | | | | They have served they purpose well, but now it's time to retire. It's one of the things that draggen in the bad dependency of chrome/common on chrome/browser, and is sufficiently small now to stub things out individually. TEST=none BUG=none Review URL: http://codereview.chromium.org/593037 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@38639 0039d316-1c4b-4281-b951-d872f2087c98
* Fix a Chrome crash which occurs in a ChromeFrame instance while servicing a ↵ananta@chromium.org2010-02-102-5/+46
| | | | | | | | | | | | | | | | | | | | | | | read request in the automation job. The crash based on the dump occurs while dereferencing a NULL message filter, which means that we received a read request for a disconnected/terminated job. This happens when a request is paused while waiting for the renderer to ack sent data packets Following fixes:- 1. NULL check the message_filter pointer before dereferencing it in URLRequestAutomationJob::ReadRawData. 2. Only complete the job when we receive a Read request for it or if we have a pending read. Added ASSERTS in OnDataAvailable to check if we receive unexpected data. Fixes bug http://code.google.com/p/chromium/issues/detail?id=34819 Bug=34819 Test=Covered by ui test. Review URL: http://codereview.chromium.org/577033 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@38583 0039d316-1c4b-4281-b951-d872f2087c98
* [GTTF] Reduce header dependencies in chrome.phajdan.jr@chromium.org2010-02-092-2/+5
| | | | | | | | | BUG=none TEST=If it compiles it is perfect. Review URL: http://codereview.chromium.org/585008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@38463 0039d316-1c4b-4281-b951-d872f2087c98
* Remove DirectoryWatcher and the only thing using it.phajdan.jr@chromium.org2010-02-091-2/+1
| | | | | | | | | | | | | DirectoryWatcher was problematic. We couldn't get it right on Linux, it can hit the disk on UI thread on Windows (Really Bad, tm). And finally, the UserScriptMaster didn't work right with it. TEST=Covered by unit_tests and browser_tests BUG=8968, 6051, 6080, 20832 Review URL: http://codereview.chromium.org/586010 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@38456 0039d316-1c4b-4281-b951-d872f2087c98
* Show the filebrowse ui rather than the download shelf in chromeos.xiyuan@chromium.org2010-02-051-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This cl displays the filebrowse ui rather than download shelf for downloads in chrom(e|ium) os. It conditionally replaces (with preprocessor macros) the Browser::OnStartDownload method to do this. The cl adds a static FileBrowseUI::OpenPopup(profile, hashArgument), which opens the file browse ui and passes it the provided hash argument. This is invoked directly from Browser::OnStartDownload. The USBMountObserver code was changed to call this static method, rather than open the popup by hand as it had been doing. I'm not sure about ownership of the Browser* returned by OpenPopup, but based on other code in the tree I assume chrome will deal with freeing it when appropriate. Before this change, USBMountObserver would add the window to registrar_ *before* showing it. Now that FileBrowseUI::OpenPopup returns a which which is already visible, this is no longer the case. I assume this won't be a problem. Commit this for rginda. Original review: http://codereview.chromium.org/555167 BUG=none TEST=none Review URL: http://codereview.chromium.org/564022 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@38222 0039d316-1c4b-4281-b951-d872f2087c98
* Add support for the IE File->Save As command. This eventually ends up in ↵ananta@chromium.org2010-02-043-1/+12
| | | | | | | | | | | | | | | | Chrome via the new automation message AutomationMsg_SaveAsAsync. Rest of the changes are to plumb this message across from IE to Chrome. Fixes bug http://code.google.com/p/chromium/issues/detail?id=24039 Bug=24039 Test=Launch IE with OptinUrls set to *. Navigate to google.com and select File->Save As. The dialog should popup. Review URL: http://codereview.chromium.org/563025 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@38145 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 38001 and 38002.darin@chromium.org2010-02-032-53/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Modify CookiePolicy to work asynchronously This change will enable us to prompt the user before setting a cookie. While we only need to prompt before setting, we actually need to make both CanSetCookie and CanGetCookies asynchronous. This is necessary in order to preserve FIFO ordering since the value returned by GetCookies depends on the changes made to the cookie DB by SetCookie. This change also includes some simplification of CookieStore. Instead of N virtual functions, I distilled it down to only 4. The remaining functions are instead expressed in terms of those. While studying all the places where we currently use CookiePolicy, I found that some of them were not appropriate. After discussing with Amit, I decided to remove the policy checks in URLRequestAutomationJob. See the comments in the code regarding this. I changed the signature of CookieMonster::GetRawCookies to GetAllCookiesForURL to better match GetAllCookies. Related to this change webkit/glue/webcookie.h grows a constructor that takes a CanonicalCookie to help clean up some code. On the Chrome side, ChromeURLRequestContext now has a ChromeCookiePolicy object. That object is threadsafe ref counted because it is passed between the UI and IO threads. It is responsible for implementing the queuing logic described above. It will also in the future trigger the Chrome UI code to actually show the setcookie prompt. Please review the state machinery changes in URLRequestHttpJob carefully. R=eroman BUG=34331 TEST=no tests yet for prompting. Review URL: http://codereview.chromium.org/564045 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@38028 0039d316-1c4b-4281-b951-d872f2087c98
* Back out trunk r37998.mark@chromium.org2010-02-032-18/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | Modify CookiePolicy to work asynchronously This change will enable us to prompt the user before setting a cookie. While we only need to prompt before setting, we actually need to make both CanSetCookie and CanGetCookies asynchronous. This is necessary in order to preserve FIFO ordering since the value returned by GetCookies depends on the changes made to the cookie DB by SetCookie. This change also includes some simplification of CookieStore. Instead of N virtual functions, I distilled it down to only 4. The remaining functions are instead expressed in terms of those. While studying all the places where we currently use CookiePolicy, I found that some of them were not appropriate. After discussing with Amit, I decided to remove the policy checks in URLRequestAutomationJob. See the comments in the code regarding this. I changed the signature of CookieMonster::GetRawCookies to GetAllCookiesForURL to better match GetAllCookies. I also filed a bug about making it even closer in functionality. Related to this change webkit/glue/webcookie.h grows a constructor that takes a CanonicalCookie to help clean up some code. On the Chrome side, ChromeURLRequestContext now has a ChromeCookiePolicy object. That object is threadsafe ref counted because it is passed between the UI and IO threads. It is responsible for implementing the queuing logic described above. It will also in the future trigger the Chrome UI code to actually show the setcookie prompt. Please review the state machinery changes in URLRequestHttpJob carefully. R=eroman BUG=34331 TEST=no tests yet for prompting. Review URL: http://codereview.chromium.org/567015 TBR=darin@chromium.org Review URL: http://codereview.chromium.org/562037 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@38002 0039d316-1c4b-4281-b951-d872f2087c98
* Modify CookiePolicy to work asynchronouslydarin@chromium.org2010-02-032-53/+18
| | | | | | | | | | | | | | | | | | | | | This change will enable us to prompt the user before setting a cookie. While we only need to prompt before setting, we actually need to make both CanSetCookie and CanGetCookies asynchronous. This is necessary in order to preserve FIFO ordering since the value returned by GetCookies depends on the changes made to the cookie DB by SetCookie. This change also includes some simplification of CookieStore. Instead of N virtual functions, I distilled it down to only 4. The remaining functions are instead expressed in terms of those. While studying all the places where we currently use CookiePolicy, I found that some of them were not appropriate. After discussing with Amit, I decided to remove the policy checks in URLRequestAutomationJob. See the comments in the code regarding this. I changed the signature of CookieMonster::GetRawCookies to GetAllCookiesForURL to better match GetAllCookies. I also filed a bug about making it even closer in functionality. Related to this change webkit/glue/webcookie.h grows a constructor that takes a CanonicalCookie to help clean up some code. On the Chrome side, ChromeURLRequestContext now has a ChromeCookiePolicy object. That object is thread-safe ref counted because it is passed between the UI and IO threads. It is responsible for implementing the queuing logic described above. It will also in the future trigger the Chrome UI code to actually show the set-cookie prompt. Please review the state machinery changes in URLRequestHttpJob carefully. R=eroman BUG=34331 TEST=no tests yet for prompting. Review URL: http://codereview.chromium.org/567015 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@37998 0039d316-1c4b-4281-b951-d872f2087c98
* DevTools: CookieMonster::GetRawCookies should return keys as well as cookies.pfeldman@chromium.org2010-02-031-4/+4
| | | | | | Review URL: http://codereview.chromium.org/565035 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@37978 0039d316-1c4b-4281-b951-d872f2087c98
* BSD port: chrome/app and chrome/browser ifdef cleaningpvalchev@google.com2010-02-012-7/+5
| | | | | | Review URL: http://codereview.chromium.org/548203 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@37714 0039d316-1c4b-4281-b951-d872f2087c98
* If the URLRequestContext has no CookiePolicy, then we shoulddarin@chromium.org2010-01-301-6/+5
| | | | | | | | | | | | | | | allow cookies instead of denying them. I broke this yesterday when I made the CookiePolicy be an optional element of the URLRequestContext. See r37624. R=pkasting BUG=none TEST=none Review URL: http://codereview.chromium.org/557073 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@37649 0039d316-1c4b-4281-b951-d872f2087c98
* Changes to support new cookie policy.darin@chromium.org2010-01-301-3/+5
| | | | | | | | | | | | | | Changes: 1- net::CookiePolicy becomes an interface. 2- Old implementaiton of CookiePolicy copied to StaticCookiePolicy. 3- ChromeULRRequestContext implements CookiePolicy. 4- HostContentSettingsMap gets a global "BlockThirdPartyCookies" pref. R=pkasting Review URL: http://codereview.chromium.org/556095 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@37624 0039d316-1c4b-4281-b951-d872f2087c98
* In IE8 new windows opened within ChromeFrame via window.open calls at times ↵ananta@chromium.org2010-01-304-25/+202
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | bypass the host network stack. In this case we don't get control over the navigation as window.open calls expect to carry the opener relationship over to the new window. This basically means that navigation occurs in Chrome and the new tab/window created by the host attaches to the newly created ExternalTabContainer instance. In IE8 the new tab opens in a new IE process, which basically uses a new automation channel to talk to Chrome. The host network stack implementation routes network requests issued by registered render views to the host browser over the automation channel. There is a timing window between the new window getting created and issuing network requests and the channel being established with the new iexplore instance. As a result network requests issued by the new window don't use the host network stack. Fix is to register the render view and process as a pending view when we get notified about the new TabContents in the original ExternalTabContainers implementation of TabContentsDelegate::AddNewContents. Any network requests issued for this view would result in the corresponding URLRequestAutomationJob instances getting created as pending as well. When the host browser connects to the new ExternalTabContainer instance, we pass over the new automation channel and tab handle to the URLRequestAutomationJob instances and resume them. This fixes bug http://code.google.com/p/chromium/issues/detail?id=33516 Bug=33516 Test=Login to gmail in IE8 in ChromeFrame. Open up a new conversation and click on New Window which opens up a tear off window. This should not bring up the login prompt again. Will think about a good approach to write a unit test for this behavior and send out a separate CL for that. Review URL: http://codereview.chromium.org/554134 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@37585 0039d316-1c4b-4281-b951-d872f2087c98
* Refactored code to allow associating workers with multiple renderers.atwilson@chromium.org2010-01-281-12/+10
| | | | | | | | | | | | | | | | SharedWorkers now gracefully handle http auth requests after their initial window has closed. BUG=27660 TEST=WorkerHttpAuth,SharedWorkerHttpAuth uitests Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=36888 Reverted and reopened due to valgrind failures. Review URL: http://codereview.chromium.org/509016 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@37365 0039d316-1c4b-4281-b951-d872f2087c98
* Fixes flakiness in session restore test. I'm adding two things:sky@chromium.org2010-01-262-0/+13
| | | | | | | | | | | | | | | | . Make the newly created popup navigate to a url. Without this session restore won't restore the tab. . Before exiting manually shutdown the session service. Without this the windows are closed, which, depending upon timing, is treated as though the user closed the window so that session restore won't restore the window. BUG=32716 TEST=this is only a test fix Review URL: http://codereview.chromium.org/552134 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@37148 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 36888 - Refactored code to allow associating workers with multiple ↵pkasting@chromium.org2010-01-231-10/+12
| | | | | | | | | | | | | | | | | renderers. SharedWorkers now gracefully handle http auth requests after their initial window has closed. BUG=27660 TEST=WorkerHttpAuth,SharedWorkerHttpAuth uitests Review URL: http://codereview.chromium.org/509016 TBR=atwilson@chromium.org Review URL: http://codereview.chromium.org/549138 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@36929 0039d316-1c4b-4281-b951-d872f2087c98
* Refactored code to allow associating workers with multiple renderers.atwilson@chromium.org2010-01-221-12/+10
| | | | | | | | | | | | SharedWorkers now gracefully handle http auth requests after their initial window has closed. BUG=27660 TEST=WorkerHttpAuth,SharedWorkerHttpAuth uitests Review URL: http://codereview.chromium.org/509016 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@36888 0039d316-1c4b-4281-b951-d872f2087c98
* Pull IOThread out of BrowserProcessImpl. Move the dns prefetching ↵willchan@chromium.org2010-01-221-0/+1
| | | | | | | | | | | initialization into IOThread. The global host resolver and dns master have changed to be member variables of IOThread. BUG=26156,26159 Review URL: http://codereview.chromium.org/553026 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@36866 0039d316-1c4b-4281-b951-d872f2087c98
* Fix for FullTabModeIE_ChromeFrameDeleteCookieTest and issues with deleting ↵tommi@chromium.org2010-01-222-1/+29
| | | | | | | | | | | persistent cookies as reported in bug 30786. TEST=Run FullTabModeIE_ChromeFrameDeleteCookieTest. BUG=32546,30786 Review URL: http://codereview.chromium.org/551101 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@36831 0039d316-1c4b-4281-b951-d872f2087c98
* Fix FullTabModeIE_ChromeFrameDeleteCookieTest. The problem was that a ↵tommi@chromium.org2010-01-212-18/+46
| | | | | | | | | | | | | | | domain cookie was being set twice although only set once by the server. The test itself needed fixing as well as an extra check for domain cookies set by a different url than the current url. There's one other problem remaining however which was initially reported in bug 30786 and I'll get on that next (bug reopened). TEST=Run the FullTabModeIE_ChromeFrameDeleteCookieTest test. BUG=32546, 30786 Review URL: http://codereview.chromium.org/546104 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@36749 0039d316-1c4b-4281-b951-d872f2087c98
* Remove support for filtering by MIME-type.jochen@chromium.org2010-01-201-1/+1
| | | | | | | | | | | Also merge kDontSendCookies and kDontStoreCookies to kNoCookies. BUG=16932 TEST=unit_tests Review URL: http://codereview.chromium.org/542056 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@36628 0039d316-1c4b-4281-b951-d872f2087c98
* Fix a Chrome crash which occurs when the chrome instance launched via ↵ananta@chromium.org2010-01-142-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | ChromeFrame is shutting down. I was not able to reproduce this locally. Based on the crash dump, it looks like the crash occurs when the sync channel used by the automation provider is shutting down and it is attempting a PostTask of OnChannelClosed. The crash occurs while posting the task to the message loop, because the message loop is invalid. This could occur if the message loop has been destroyed. The message loop is destroyed when the module refcount drops to zero. The automation provider releases the module ref count in OnChannelError. In theory there is a race condition here, i.e. the message loop could be destroyed before the ExternalTabContainer, etc are destroyed. Suggested fix is to call AddRefModule which grabs a reference on the UI message loop in the automation provider constructor and release it in the destructor. We also close the channel before invoking ReleaseModule in the destructor. Fixes bug http://code.google.com/p/chromium/issues/detail?id=31621 Bug=31621 Review URL: http://codereview.chromium.org/542036 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@36240 0039d316-1c4b-4281-b951-d872f2087c98
* Attempt 2 at landing this.ananta@chromium.org2010-01-083-5/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-083-44/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-083-5/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Authorization headers set using XHR with ChromeFrame were stripped in the ↵ananta@chromium.org2009-12-281-1/+0
| | | | | | | | | | | | | | | | | | | outgoing HTTP requests sent via the host network stack. Fix is to remove the authorization header from the list of filtered headers. Added a unit test for this. Fixes bug http://code.google.com/p/chromium/issues/detail?id=23103 Bug=23103 Test=Covered by unit test. Review URL: http://codereview.chromium.org/519013 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35319 0039d316-1c4b-4281-b951-d872f2087c98
* Multiple chrome frame activex controls should instantiate and navigate ↵ananta@chromium.org2009-12-181-1/+2
| | | | | | | | | | | | | | | | | | | | | | | correctly in IE. This was not the case due to a race condition between put_src getting called for subsequent activex instances and the external tab to hold the chrome frame instance getting created. Fix is to pass in the URL if we have it when the automation client is initialized to launch the chrome automation server. If not we navigate when the external tab is created. To achieve this we stuff in all relevant parameters into a structure which is populated when the automation client is initialized. I also changed the CreateExternalTab message to carry the referrer for the initial navigation. Fixes http://code.google.com/p/chromium/issues/detail?id=28236 Test=added unit tests for the same. The firefox one is not working at this point. Disabled this test for now while I debug it. Bug=28236 Review URL: http://codereview.chromium.org/500123 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@34985 0039d316-1c4b-4281-b951-d872f2087c98
* Enable login prompt (http auth) tests on non-windows platformsatwilson@chromium.org2009-12-181-5/+0
| | | | | | | | TEST=LoginPromptTest.* Review URL: http://codereview.chromium.org/501091 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@34938 0039d316-1c4b-4281-b951-d872f2087c98
* SPDY: augment Strict Transport Security with the beginnings of SPDY upgrade.agl@chromium.org2009-12-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | This adds an opportunistic flag to the information that we store in the Strict Transport Security State. Given this, STSS might be misnamed now, but renaming it in this patch would add huge amounts of noise. We process the 'X-Bodge-Transport-Security' header which has the same format as the STS header. When we see this on an HTTP connection, we'll probe for a clean HTTPS path to the host and then remember it. This header should be considered mutually exclusive with STS, although this isn't enforced in the code. The remembered flag is currently ignored by the rest of the code. This will be addressed in a future patch. The header should be called 'Opportunistic-Transport-Security' in the future, but we have some issues to work out before we take that name. http://codereview.chromium.org/456011 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@34380 0039d316-1c4b-4281-b951-d872f2087c98
* The ChromeFrame net tests randomly crash in the url request redirect tests ↵ananta@chromium.org2009-12-111-0/+7
| | | | | | | | | | | | | | | | | | | | | | on the chrome frame builder. Some debugging revealed that we send over two redirect responses from the IE host network stack implementation to Chrome, which causes a crash in the url request automation job while dereferencing a NULL request. Two redirect responses are sent in the following scenario:- 1. We received a redirect notification in our bind status callback. We abort the binding and return E_ABORT. 2. Eventually we receive a call in our bind status callback implementation of OnResponse even after the binding was aborted. This causes the response to be sent twice. Added a check for a NULL binding and a trace in the IE host network stack implementation. I also added a NOTREACHED in the url request automation job if we ever receive a message for an automation job which has a NULL request. Bug=30118 Review URL: http://codereview.chromium.org/487028 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@34360 0039d316-1c4b-4281-b951-d872f2087c98
* ChromeFrame uses the IPC automation channel to talk to Chrome. The IPC ↵ananta@chromium.org2009-12-103-0/+146
| | | | | | | | | | | | | | | | | messages sent by ChromeFrame are handled by the AutomationProvider class in Chrome, which also handles other IPC's not used by ChromeFrame. We now have a new class ChromeFrameAutomationProvider which derives from the AutomationProvider class and validates that incoming IPC messages are valid ChromeFrame messages. Bug=29931 Test=Covered by unit test Review URL: http://codereview.chromium.org/476008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@34290 0039d316-1c4b-4281-b951-d872f2087c98
* Use gfx::Point instead of GET_X/Y_LPARAM to reduce the dependency on ATL. jhawkins@chromium.org2009-12-071-2/+3
| | | | | | | | | | | Patch from Thiago Farina <thiago.farina@gmail.com> Original review: http://codereview.chromium.org/465004 BUG=5027 TEST=None Review URL: http://codereview.chromium.org/460121 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33996 0039d316-1c4b-4281-b951-d872f2087c98
* Reduce the logging output when running startup tests on linux/mac.tony@chromium.org2009-12-031-1/+1
| | | | | | Review URL: http://codereview.chromium.org/464021 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33717 0039d316-1c4b-4281-b951-d872f2087c98
* Speculative fix for ChromeFrame crash in bug ↵ananta@chromium.org2009-12-022-6/+8
| | | | | | | | | | | | | | | | | | | | http://code.google.com/p/chromium/issues/detail?id=29025 The crash occurs while dereferencing the automation channel to send out the SetCookie IPC message on the automation channel to the host browser. Based on what I could see from the crash dump and the code it seems like there could be a scenario where the AutomationResourceContext object could be destroyed while the AutomationCookieStore object is still around and thus ends up with a stale pointer which crashes when dereferenced. Fix is to ensure that all related code paths hold on to a refcounted AutomationResourceContext instance. I will look into whether it is possible to come up with a unit test for this. Bug=29025 Review URL: http://codereview.chromium.org/450020 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33524 0039d316-1c4b-4281-b951-d872f2087c98
* Integrate BlacklistManager with Profile.phajdan.jr@chromium.org2009-11-301-3/+0
| | | | | | | | | | | | | Now each Profile has a BlacklistManager that maintains a compiled Blacklist for that Profile. The system does not yet pause user-initiated web requests until the blacklist system is ready. However, the code is not supposed to be ready, and is hidden behind a --enable-privacy-blacklists command-line flag. TEST=Covered by browser_test. BUG=21541 Review URL: http://codereview.chromium.org/371063 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33290 0039d316-1c4b-4281-b951-d872f2087c98
* ChromeFrame's host network stack implementation for IE full tab mode ↵ananta@chromium.org2009-11-241-14/+6
| | | | | | | | | | | | | | | | | | | | | | | | implicitly follows redirects. When Chrome receives a notification about a redirect it also attempts to follow the redirect request. While this works in most cases, some sites actually returned an error for the second request initiated by Chrome. Fix is to abort the request in urlmon, when we receive a notification about a redirect. I also fixed the IsRedirectResponse function in the UrlRequestAutomationJob class to only treat 301, 302, 303 and 307 as redirect codes on the same lines as the default http job. Test=covered by existing network tests. I also verified that http://code.google.com/p/chromium/issues/detail?id=25643 works with this CL. Fixes http://code.google.com/p/chromium/issues/detail?id=28296 Bug=28296 Review URL: http://codereview.chromium.org/402107 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32896 0039d316-1c4b-4281-b951-d872f2087c98
* Assorted cleanup.estade@chromium.org2009-11-231-4/+5
| | | | | | | | process: grep for TODO(port), find cruft, clean it up Review URL: http://codereview.chromium.org/427004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32844 0039d316-1c4b-4281-b951-d872f2087c98
* Allow extension port connection requests to provide tab information.mad@chromium.org2009-11-192-4/+13
| | | | | | | | | | For Siggi: http://codereview.chromium.org/408015 BUG=0 TEST=none git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32536 0039d316-1c4b-4281-b951-d872f2087c98
* Cleanup some callers now that the restriction that ↵eroman@chromium.org2009-11-192-12/+1
| | | | | | | | | | | | | | | ChromeURLRequestContextGetter be released from the IO thread is gone. This was an anoyance for consumers of URLRequestContextGetter, as they would play tricks doing manual AddRef/Release. The actual removal of this policy happened in: r32129. BUG=None Test=Existing tests don't crash/leak. Review URL: http://codereview.chromium.org/332006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32488 0039d316-1c4b-4281-b951-d872f2087c98
* The AutomationMsg_SetCookie IPC should be channeled to the automation cookie ↵ananta@chromium.org2009-11-171-1/+6
| | | | | | | | | | | | store for ChromeFrame. This ensures that the automation client would receive a callback when the cookie is set on the store. Bug=none Review URL: http://codereview.chromium.org/403004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32188 0039d316-1c4b-4281-b951-d872f2087c98
* amit, please review everything, jam please review the changes to the ↵ananta@chromium.org2009-11-173-259/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | tab_contents and the renderer_host sources. Remove the AutomationProfileImpl class which wraps the Chrome profile for an external tab container, which hosts ChromeFrame. This object was used to carry a custom URL request context which was used to intercept HTTP requests and cookie requests issued by external tabs. However as the life time of the automation profile class depended on the lifetime of the external tab container object this caused a number of crashes in objects which held on to the automation profile pointer retrieved from the associated tab contents. This does not happen in a regualar Chrome browser instance as the profile is deleted at the very end. We can associate the automation URL request context with the underlying tab_contents which would eventually percolate down to the resource message filter. Doing this would avoid the need for the AutomationProfile class. This CL achieves that. Bug=27695,27662 Review URL: http://codereview.chromium.org/385117 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32127 0039d316-1c4b-4281-b951-d872f2087c98
* Fixes almost all of the rest of lint errors in the chrome/ directory (minus ↵erg@google.com2009-11-138-20/+20
| | | | | | | | the really hard ones which will need actual review instead of rubber-stamping.) Review URL: http://codereview.chromium.org/386026 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31932 0039d316-1c4b-4281-b951-d872f2087c98
* Small clean-up to not expose base::Process from RenderProcesHost, and ↵jam@chromium.org2009-11-131-1/+2
| | | | | | | | instead only expose base::ProcessHandle. Precursor to moving process startup off the UI thread. Review URL: http://codereview.chromium.org/387047 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31922 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 31873 - Revert 31862 Ensure AutomationMsg_SetCookieAsync is sent on ↵levin@chromium.org2009-11-131-1/+11
| | | | | | | | | | | | | IO thread. Restoring this change as it seems the blame list was incorrect on some bot and this change wasn't to blame but r31865 was in fact the real culprit. TBR=stoyan@chromium.org Review URL: http://codereview.chromium.org/384116 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31892 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 31862 - Ensure AutomationMsg_SetCookieAsync is sent on IO thread.levin@chromium.org2009-11-131-11/+1
| | | | | | | | | | | | These tests started failing with this checkin: AuthenticateSuccess AuthenticateWithTokenSuccess Review URL: http://codereview.chromium.org/387042 TBR=stoyan@chromium.org Review URL: http://codereview.chromium.org/389031 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31873 0039d316-1c4b-4281-b951-d872f2087c98
* Ensure AutomationMsg_SetCookieAsync is sent on IO thread.stoyan@chromium.org2009-11-131-1/+11
| | | | | | | | | If SetCookie is invoked via automation and load_requests_via_automation is true, the IPC will be sent back from the UI thread. BUG=27568 Review URL: http://codereview.chromium.org/387042 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31862 0039d316-1c4b-4281-b951-d872f2087c98
* ChromeFrame HTTP requests would randomly fail if we navigated to multiple ↵ananta@chromium.org2009-11-114-4/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | HTTP sites. This was because the automation resource message filter tracked HTTP requests based on the request ids which are generated by the renderer process. As a result a new request would get created say with id 0, while an existing request would end in ChromeFrame causing the new request to incorrectly shutdown. Fix is to revert back to the original way of tracking requests with an auto incrementing id. The automation url job maintains both ids now, i.e. the automation request id and the chrome request id. The download notification receives the automation id and basically looks up the associated automation request id and sends the notification back to ChromeFrame. This fixes bug http://code.google.com/p/chromium/issues/detail?id=27401 Other fixes in this CL include the following:- 1. The active document instance would never get destroyed. This was because we call ShowUI on the doc host which maintains a reference. We need to call HideUI in Setsite of NULL, which releases the reference. 2. When the active x instance is shutting down we try to shutdown all running requests in the OnDestroy handler. To ensure that the request is deleted from the request map and released in the same thread which created it we post a task back to the ui thread which never runs as the window is being destroyed. Fix is to create a message only window with every urlmonrequest instance which supports task marshaling. Tests in a future CL. Bug=27401 Review URL: http://codereview.chromium.org/386008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31731 0039d316-1c4b-4281-b951-d872f2087c98
* Rename unused "SSL" related automation methods to be generic, since that's ↵johnnyg@chromium.org2009-11-112-16/+16
| | | | | | | | | | | | what these methods actually do, and so I can repurpose them for a different info-bar test. BUG=none TEST=none Review URL: http://codereview.chromium.org/385029 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31718 0039d316-1c4b-4281-b951-d872f2087c98
* A large number of style nits in preparation for turning on automated cpplint.py.erg@google.com2009-11-112-3/+3
| | | | | | Review URL: http://codereview.chromium.org/385023 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31669 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-03-30 10:23:24 +0000