summaryrefslogtreecommitdiffstats
path: root/chrome_frame/test/net/test_automation_provider.cc
Commit message (Collapse)AuthorAgeFilesLines
* Introduce GURL::SchemeIsHttpFamily(), which returns true for http and https.cdn@chromium.org2013-08-221-1/+1
| | | | | | | | | | BUG=274679 TEST=N/A TBR=cbentzel, jamesr, simonjam, tzik, stevet, mpcomplete Review URL: https://chromiumcodereview.appspot.com/23064011 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@218893 0039d316-1c4b-4281-b951-d872f2087c98
* Rename FilePath -> base::FilePath in various toplevel directoriesbrettw@chromium.org2013-02-101-1/+1
| | | | | | Review URL: https://codereview.chromium.org/12211108 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@181639 0039d316-1c4b-4281-b951-d872f2087c98
* Provide mutable members of UrlRequestContext via pure-virtual interface. ↵pauljensen@chromium.org2012-11-071-0/+2
| | | | | | | | | | Create a pure-virtual interface called HttpUserAgentSettings that provides access to the Accept-Language, Accept-Charset, and User-Agent HTTP headers. Each UrlRequestContext should have a HttpUserAgentSettings implementation attached via set_http_user_agent_settings(). BUG=146596 Review URL: https://chromiumcodereview.appspot.com/10918279 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@166425 0039d316-1c4b-4281-b951-d872f2087c98
* Refactoring: ProtocolHandler::MaybeCreateJob and other functions take ↵shalev@chromium.org2012-08-241-3/+6
| | | | | | | | | | | | | | NetworkDelegate as argument This change goes a long way to prepare for removing NetworkDelegate from URLRequestContext. TBR=sky@chromium.org, michaeln@chromium.org, benjhayden@chromium.org, brettw@chromium.org, ben@chromium.org, davemoore@chromium.org, zelidrag@chromium.org, mnissler@chromium.org, thestig@chromium.org, asargent@chromium.org, jhawkins@chromium.org, bulach@chromium.org BUG=crbug.com/142945 Review URL: https://chromiumcodereview.appspot.com/10855209 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@153133 0039d316-1c4b-4281-b951-d872f2087c98
* Don't perform or require a successful Chrome shutdown at the end of Chrome ↵erikwright@chromium.org2012-03-141-1/+2
| | | | | | | | | | | | | | | | | Frame Net Tests. These tests launch Chrome in ways that differ substantially from the norm. Hence, recording and forcing the diagnosis/fixing of failures in Chrome internal code here is an unreasonably high bar. The middle-term objective is to actually not launch Chrome here at all. This CL supports the short term objective of getting the tests on the waterfall. BUG=None TEST=chrome_frame_net_tests.exe Review URL: http://codereview.chromium.org/9677042 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@126574 0039d316-1c4b-4281-b951-d872f2087c98
* This goes most of the way to re-enabling chrome_frame_net_tests by making it ↵joi@chromium.org2011-12-121-2/+9
| | | | | | | | | | | | | | a content::BrowserMainParts. The tests are still disabled until we are able to test them on IE8 and older; on IE9 all tests currently pass except for a few that hang. Additionally, this makes chrome_frame_net_tests determine protocol version using the exact same version information as npchrome_frame.dll does, so that version mismatch due to the RC dependency problems we have sometimes seen should not happen any more with this test suite. While in there, I also updated the poor_mans_trybot.bat script. BUG=105435 Review URL: http://codereview.chromium.org/8894008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@114080 0039d316-1c4b-4281-b951-d872f2087c98
* Deprecate RegisterProtocolFactory/(Un)RegisterInterceptor.willchan@chromium.org2011-07-191-5/+5
| | | | | | | | | | | | Mark those APIs as private and friend existing uses. BUG=none TEST=none Review URL: http://codereview.chromium.org/7397008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@92992 0039d316-1c4b-4281-b951-d872f2087c98
* Fix ChromeFrame net tests which have broken since revision 70089 which added ↵ananta@chromium.org2011-01-141-2/+1
| | | | | | | | | | | | | | | | | | a named testing interface to the automation provider. The testing automation provider was incorrectly assuming that the tab handle would be a parameter in the TabLoaded message. This changed with jam's change to clean up the automation messages used by chrome frame. The other bug was with the AutomationMsg_Hello message which was passing an incorrect protocol version to chrome frame. BUG=none TEST=ChromeFrame net tests should run. TBR=amit Review URL: http://codereview.chromium.org/6324002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@71422 0039d316-1c4b-4281-b951-d872f2087c98
* Make IPC::Channel::Listener:OnMessageReceived have a return value indicating ↵jam@chromium.org2010-12-241-3/+3
| | | | | | | | | whether a message was processed or not. TBR=brettw Review URL: http://codereview.chromium.org/5978003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@70139 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 68944 - Revert "Add named testing interface."nirnimesh@chromium.org2010-12-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reverting the revert of named interface CL. Followup CL which addresses Pawel's comments is up at http://codereview.chromium.org/5967003/ http://src.chromium.org/viewvc/chrome?view=rev&revision=67300 The change has been approved conditionally, i.e. if the outstanding review comments are handled in a follow-up as the top priority. Two weeks have passed, and I have not seen the follow-up. It is risky to keep this change in the tree, as it is already non-trivial to revert. Conflicts: chrome/browser/automation/automation_provider.cc chrome/test/ui/named_interface_uitest.cc ipc/ipc_channel_posix.cc TBR=nirnimesh BUG=chromium-os:8512 TEST=none Review URL: http://codereview.chromium.org/5707006 TBR=phajdan.jr@chromium.org BUG=chromium-os:8512 TEST=ui_tests --gtest_filter=NamedInterfaceTest.FLAKY_BasicNamedInterface Review URL: http://codereview.chromium.org/6012006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@70089 0039d316-1c4b-4281-b951-d872f2087c98
* Revert "Add named testing interface."phajdan.jr@chromium.org2010-12-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | http://src.chromium.org/viewvc/chrome?view=rev&revision=67300 The change has been approved conditionally, i.e. if the outstanding review comments are handled in a follow-up as the top priority. Two weeks have passed, and I have not seen the follow-up. It is risky to keep this change in the tree, as it is already non-trivial to revert. Conflicts: chrome/browser/automation/automation_provider.cc chrome/test/ui/named_interface_uitest.cc ipc/ipc_channel_posix.cc TBR=nirnimesh BUG=chromium-os:8512 TEST=none Review URL: http://codereview.chromium.org/5707006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@68944 0039d316-1c4b-4281-b951-d872f2087c98
* net: Remove typedef net::URLRequestJob URLRequestJob;tfarina@chromium.org2010-12-111-2/+2
| | | | | | | | | BUG=64263 TEST=compiled locally, trybots Review URL: http://codereview.chromium.org/5607004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@68935 0039d316-1c4b-4281-b951-d872f2087c98
* Get rid of std::wstring version of HasSwitch.tfarina@chromium.org2010-12-081-1/+1
| | | | | | | | | BUG=24672 TEST=trybots Review URL: http://codereview.chromium.org/5649003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@68650 0039d316-1c4b-4281-b951-d872f2087c98
* net: Remove typedef net::URLRequest URLRequest;tfarina@chromium.org2010-11-301-5/+5
| | | | | | | | | BUG=64263 TEST=compiled locally, trybots Review URL: http://codereview.chromium.org/5384002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67762 0039d316-1c4b-4281-b951-d872f2087c98
* Add named testing interface. This allows you to connect to a pre-existing ↵nirnimesh@chromium.org2010-11-241-1/+1
| | | | | | | | | | | | | | | | | | | | | Chrome process and run tests on it. This is an addition to the low level interface underlying testing frameworks like PyAuto and WebDriver. Normally, test frameworks communicate with Chrome over an unnamed socket pair on POSIX. The test creates the socket pair and then launches the browser as a child process, passing an open file descriptor for one end of the socket to the browser. This change adds a command line switch that, when passed to the browser, causes it to listen on a named socket instead, eliminating this parent/child process requirement. Therefore, you can potentially connect any number of tests to a preexisting browser process. For ChromeOS, this allows you to run tests on the instance of Chrome that is launched on startup, which controls things like the login and lock screens, the battery meter, the wireless UI, etc. Currently there is no way to run tests on a pre-existing Chrome instance. Eventually this will also allow you to connect both PyAuto and WebDriver to the same Chrome instance and run both in the same test. If you pass the browser the following command line switch: ./chrome --testing-channel=NamedTestingInterface:/path/to/file This causes the browser to listen for incoming connections. An AutomationProxy can connect to the browser by connecting a Unix domain socket to the specified path and control the browser over the socket. This is currently only for POSIX. Windows support will come in a future change. Also, this initial change only allows one connection; multiple connection support will come in a future change. BUG=chromium-os:8512 TEST=Run Chrome with --testing-interface=/var/tmp/NamedTestingInterface, then run NamedInterfaceTest.BasicNamedInterface under ui_tests. Review URL: http://codereview.chromium.org/4202004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67300 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 66840 - Add named testing interface. This allows you to connect to a ↵kkania@chromium.org2010-11-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | pre-existing Chrome process and run tests on it. This is an addition to the low level interface underlying testing frameworks like PyAuto and WebDriver. Normally, test frameworks communicate with Chrome over an unnamed socket pair on POSIX. The test creates the socket pair and then launches the browser as a child process, passing an open file descriptor for one end of the socket to the browser. This change adds a command line switch that, when passed to the browser, causes it to listen on a named socket instead, eliminating this parent/child process requirement. Therefore, you can potentially connect any number of tests to a preexisting browser process. For ChromeOS, this allows you to run tests on the instance of Chrome that is launched on startup, which controls things like the login and lock screens, the battery meter, the wireless UI, etc. Currently there is no way to run tests on a pre-existing Chrome instance. Eventually this will also allow you to connect both PyAuto and WebDriver to the same Chrome instance and run both in the same test. If you pass the browser the following command line switch: ./chrome --testing-channel=NamedTestingInterface:/path/to/file This causes the browser to listen for incoming connections. An AutomationProxy can connect to the browser by connecting a Unix domain socket to the specified path and control the browser over the socket. This is currently only for POSIX. Windows support will come in a future change. Also, this initial change only allows one connection; multiple connection support will come in a future change. BUG=chromium-os:8512 TEST=Run Chrome with --testing-interface=/var/tmp/NamedTestingInterface, then run NamedInterfaceTest.BasicNamedInterface under ui_tests. Review URL: http://codereview.chromium.org/4202004 TBR=nirnimesh@chromium.org Review URL: http://codereview.chromium.org/5177007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66856 0039d316-1c4b-4281-b951-d872f2087c98
* Add named testing interface. This allows you to connect to a pre-existing ↵nirnimesh@chromium.org2010-11-191-1/+1
| | | | | | | | | | | | | | | | | | | | | Chrome process and run tests on it. This is an addition to the low level interface underlying testing frameworks like PyAuto and WebDriver. Normally, test frameworks communicate with Chrome over an unnamed socket pair on POSIX. The test creates the socket pair and then launches the browser as a child process, passing an open file descriptor for one end of the socket to the browser. This change adds a command line switch that, when passed to the browser, causes it to listen on a named socket instead, eliminating this parent/child process requirement. Therefore, you can potentially connect any number of tests to a preexisting browser process. For ChromeOS, this allows you to run tests on the instance of Chrome that is launched on startup, which controls things like the login and lock screens, the battery meter, the wireless UI, etc. Currently there is no way to run tests on a pre-existing Chrome instance. Eventually this will also allow you to connect both PyAuto and WebDriver to the same Chrome instance and run both in the same test. If you pass the browser the following command line switch: ./chrome --testing-channel=NamedTestingInterface:/path/to/file This causes the browser to listen for incoming connections. An AutomationProxy can connect to the browser by connecting a Unix domain socket to the specified path and control the browser over the socket. This is currently only for POSIX. Windows support will come in a future change. Also, this initial change only allows one connection; multiple connection support will come in a future change. BUG=chromium-os:8512 TEST=Run Chrome with --testing-interface=/var/tmp/NamedTestingInterface, then run NamedInterfaceTest.BasicNamedInterface under ui_tests. Review URL: http://codereview.chromium.org/4202004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66840 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 66350 - Add named testing interface. This allows you to connect to a ↵nirnimesh@chromium.org2010-11-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | pre-existing Chrome process and run tests on it. This is an addition to the low level interface underlying testing frameworks like PyAuto and WebDriver. Normally, test frameworks communicate with Chrome over an unnamed socket pair on POSIX. The test creates the socket pair and then launches the browser as a child process, passing an open file descriptor for one end of the socket to the browser. This change adds a command line switch that, when passed to the browser, causes it to listen on a named socket instead, eliminating this parent/child process requirement. Therefore, you can potentially connect any number of tests to a preexisting browser process. For ChromeOS, this allows you to run tests on the instance of Chrome that is launched on startup, which controls things like the login and lock screens, the battery meter, the wireless UI, etc. Currently there is no way to run tests on a pre-existing Chrome instance. Eventually this will also allow you to connect both PyAuto and WebDriver to the same Chrome instance and run both in the same test. If you pass the browser the following command line switch: ./chrome --testing-channel=NamedTestingInterface:/path/to/file This causes the browser to listen for incoming connections. An AutomationProxy can connect to the browser by connecting a Unix domain socket to the specified path and control the browser over the socket. This is currently only for POSIX. Windows support will come in a future change. Also, this initial change only allows one connection; multiple connection support will come in a future change. BUG=chromium-os:8512 TEST=Run Chrome with --testing-interface=/var/tmp/NamedTestingInterface, then run NamedInterfaceTest.BasicNamedInterface under ui_tests. Review URL: http://codereview.chromium.org/4202004 TBR=nirnimesh@chromium.org Review URL: http://codereview.chromium.org/5139001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66368 0039d316-1c4b-4281-b951-d872f2087c98
* Add named testing interface. This allows you to connect to a pre-existing ↵nirnimesh@chromium.org2010-11-171-1/+1
| | | | | | | | | | | | | | | | | | | | | Chrome process and run tests on it. This is an addition to the low level interface underlying testing frameworks like PyAuto and WebDriver. Normally, test frameworks communicate with Chrome over an unnamed socket pair on POSIX. The test creates the socket pair and then launches the browser as a child process, passing an open file descriptor for one end of the socket to the browser. This change adds a command line switch that, when passed to the browser, causes it to listen on a named socket instead, eliminating this parent/child process requirement. Therefore, you can potentially connect any number of tests to a preexisting browser process. For ChromeOS, this allows you to run tests on the instance of Chrome that is launched on startup, which controls things like the login and lock screens, the battery meter, the wireless UI, etc. Currently there is no way to run tests on a pre-existing Chrome instance. Eventually this will also allow you to connect both PyAuto and WebDriver to the same Chrome instance and run both in the same test. If you pass the browser the following command line switch: ./chrome --testing-channel=NamedTestingInterface:/path/to/file This causes the browser to listen for incoming connections. An AutomationProxy can connect to the browser by connecting a Unix domain socket to the specified path and control the browser over the socket. This is currently only for POSIX. Windows support will come in a future change. Also, this initial change only allows one connection; multiple connection support will come in a future change. BUG=chromium-os:8512 TEST=Run Chrome with --testing-interface=/var/tmp/NamedTestingInterface, then run NamedInterfaceTest.BasicNamedInterface under ui_tests. Review URL: http://codereview.chromium.org/4202004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66350 0039d316-1c4b-4281-b951-d872f2087c98
* Part 2 of reapplying r64637.erg@google.com2010-11-101-1/+1
| | | | | | | | | | | | | Move the automation message files from chrome/test/automation to chrome/common/. This requires a temporary override to chrome/common/DEPS until Part 3 lands. BUG=51409 TEST=compiles Review URL: http://codereview.chromium.org/4758001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@65695 0039d316-1c4b-4281-b951-d872f2087c98
* Revert "Refactor automation messages." due to mysterious problems on mac.erg@google.com2010-11-011-1/+1
| | | | | | | | | | | | | This reverts commit c1c1fed998ee4d839bfe256150e5e59220ebc0ef (r64637). TBR=nirnimesh@ BUG=51409 TEST=none Review URL: http://codereview.chromium.org/4194007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@64644 0039d316-1c4b-4281-b951-d872f2087c98
* Refactor automation messages.erg@google.com2010-11-011-1/+1
| | | | | | | | | | | | | | | | | automation_messages used to live in chrome/test/automation, when it's needed by browser and chrome_frame. When I started lifting code out of headers and into implementation files, I was getting link errors and temporarily solved the problem by compiling the cc files manually into libbrowser.a. Now this is part of chrome/common/ which is included by all targets needed. While doing this, discover that automation IPC redefines the ContextMenuParams struct. Rename it to MiniContextMenuParams. BUG=51409 TEST=none Review URL: http://codereview.chromium.org/4200007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@64637 0039d316-1c4b-4281-b951-d872f2087c98
* ChromeFrame network tests were broken since the change to honor the ↵ananta@chromium.org2010-10-261-1/+17
| | | | | | | | | | | | | | | | | | | | | | automation protocol version in ChromeFrame which basically breaks the automation connection if the protocols don't match. While this is fine when chrome is the automation client, it breaks chrome frame net tests because when the automation channel is established the automation provider sends over the version of the current module in the hello message. In the case when the current module is chrome the version goes over correctly. For chrome frame net tests there is no version string. Hence the channel never gets established. Fix is to retrieve the protocol version via a virtual protected function in the automation provider. The testing automation provider overrides this function in the network tests and returns the version of chrome.dll TBR=amit,robertshield Review URL: http://codereview.chromium.org/4160002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@63860 0039d316-1c4b-4281-b951-d872f2087c98
* Convert LOG(INFO) to VLOG(1) - chrome_frame/.pkasting@chromium.org2010-10-191-2/+2
| | | | | | | | | | Plus a couple misc. cleanups. BUG=none TEST=none Review URL: http://codereview.chromium.org/3850002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@63095 0039d316-1c4b-4281-b951-d872f2087c98
* Fix the ChromeFrame net test failures. These tests started failing since the ↵ananta@chromium.org2010-10-121-3/+4
| | | | | | | | | | | | | | | | | | change to return true from the AutomationResourceMessageFilter::OnMessageReceived for network request IPCs. ChromeFrame net tests also have a AutomationResourceMessageFilter instance which is not registered as a real message filter and is instead invoked from the TestAutomationProvider. Fix is to remove the dummy AutomationResourceMessageFilter instance and instead register the filter as a real message filter. To achieve this the automation_resource_message_filter_ member in the AutomationProvider class is now protected. TBR=tommi Review URL: http://codereview.chromium.org/3741001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@62341 0039d316-1c4b-4281-b951-d872f2087c98
* Attempt 2 at fixing the chrome frame net tests hang on the builders. This ↵ananta@chromium.org2010-07-141-1/+6
| | | | | | | | | | | | | | | | hang occurs because of a race condition in registering the http/https protocol factories. The net tests registers a protocol factory and the Chrome AutomationResourceMessageFilter also registers factories. If the net tests ends up being first in the chain then the requests are incorrectly dropped. Fix is to register the net tests protocol factory before instantiating the AutomationResourceMessageFilter. TBR=stoyan Review URL: http://codereview.chromium.org/2959013 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@52366 0039d316-1c4b-4281-b951-d872f2087c98
* Attempt to fix the chrome frame net tests failures on the builders. There ↵ananta@chromium.org2010-07-141-2/+2
| | | | | | | | | | | | | | | | | seems to be a race condition causing the tests to hang on startup on the builder. It appears that on chrome frame net tests startup we process an initial HTTP head request in the test automation provider factory and end up sending this as the response to IE instead of the expected dummy chrome frame page. This causes the tests to hang. Fix is to also check for a valid tab handle in the test automation provider factory instead of just asserting for the same. TBR=amit Review URL: http://codereview.chromium.org/2951015 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@52280 0039d316-1c4b-4281-b951-d872f2087c98
* In IE8 new windows opened within ChromeFrame via window.open calls at times ↵ananta@chromium.org2010-01-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Tommi, please review everything. John please review the changes to ↵ananta@chromium.org2009-11-211-6/+14
| | | | | | | | | | | | | | | | | | plugin_service.cc/.h The test automation provider registers itself as a protocol factory for http/https requests. This is to ensure that intercepts set by the url request network tests work correctly. I was seeing these tests fail consistently on my setup as their intercept function would never get called. The other change is to add a simple mechanism based on a boolean flag to disable browser side plugins like gears which also intercept network requests and expect to be called on the IO thread. The chrome frame network tests run in a relatively simple environment where the network tests run in a separate thread (not the IO thread) which causes a number of DCHECKS to fire in debug build test runs. The flag used to determine whether browser plugins are loaded defaults to true. Review URL: http://codereview.chromium.org/414017 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32739 0039d316-1c4b-4281-b951-d872f2087c98
* Basic wiring to enable downloads for CF's host browser network stack. A ↵tommi@chromium.org2009-11-071-1/+7
| | | | | | | | 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
* Initial import of the Chrome Frame codebase. Integration in chrome.gyp ↵slightlyoff@chromium.org2009-09-241-0/+89
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
generated by cgit v1.1 at 2025-03-01 20:29:06 +0000