summaryrefslogtreecommitdiffstats
path: root/chrome/browser/net/proxy_service_factory.cc
Commit message (Collapse)AuthorAgeFilesLines
* Call scoped_refptr<T>::get() rather than relying on implicit "operator T*"rsleevi@chromium.org2013-06-111-1/+1
| | | | | | | | | | | | | | | | | | | This upates calls to bound temporary objects to also use get(). While it has the same semantic equivalence to the existing code, this generally represents a dangerous pattern - indeed, part of the whole motivation for this change is to make this anti-pattern very visible to authors. This change simply updates all of the call sites, to allow the "operator T*" to be removed and preventing new instances. The existing instances will then be reviewed for "suspicious" changes and updated to use/pass scoped_refptr<T> rather than T*, as appropriate. BUG=110610 TBR=darin Review URL: https://codereview.chromium.org/15984016 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@205560 0039d316-1c4b-4281-b951-d872f2087c98
* Remove calls to URLRequestContext::network_delegate() in chrome browser code.tedv@chromium.org2013-03-111-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | These changes are motivated by a desire to remove external accesses to a request context's delegate. (If a block of code needs to use a NetworkDelegate, it should not query the URLRequestContext for it, but instead should already have access to whatever delegate the context uses.) Two interfaces changed to support this: ProxyServiceFactory::CreateProxyService() now accepts separate arguments for URLRequestContext* and NetworkDelegate*, and its call locations (most notably from chrome/browser/io_thread.cc) specify the network delegate the context used. Note that this means that if someone gets a non-const URLRequestContext pointer and later calls set_network_delegate() on it, the ProxyServiceFactory would not match the context's delegate. This doesn't happen now, and I can't even think of why we might want to do that, but it's worth noting for the record that this would be a Bad Thing(tm). The constructor of TestURLRequest also accepts a separate argument for the network delegate (as an alternative to using the context's delegate). Several tests were updated to clarify their url requests have no network delegate. BUG=146587 Review URL: https://chromiumcodereview.appspot.com/12313094 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@187336 0039d316-1c4b-4281-b951-d872f2087c98
* Rename FilePath to base::FilePath and use new location of ↵brettw@chromium.org2013-02-081-1/+1
| | | | | | | | string_number_conversions in some chrome subdirectories. Review URL: https://codereview.chromium.org/12218065 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@181564 0039d316-1c4b-4281-b951-d872f2087c98
* Improve performance of proxy resolver by tracing DNS dependencies.eroman@chromium.org2013-01-301-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | This replaces the multi-threaded V8 proxy resolver implementation, with a faster single-threaded one. The single-threaded version uses some magic to avoid blocking on DNS dependencies, so it is able to handle more parallel requests than the multi-threaded one. Design document: https://docs.google.com/a/chromium.org/document/d/16Ij5OcVnR3s0MH4Z5XkhI9VTPoMJdaBn9rKreAmGOdE/edit This has the benefit of reducing the number of threads that Chrome uses for PAC evaluation, while at the same time speeding up proxy resolving for PAC scripts that do DNS resolving (due to better parallelism). I ran a benchmark to evaluate the effectiveness of this new approach. The benchmark simulates loading the http://www.newyorktimes.com webpage with slow DNS (where each DNS resolve takes 2 seconds), and a maximum DNS resolver parallelism of 10 requests. This webpage resolves the proxy for 221 URLs, across 40 unique hostnames. - Proxy resolving using the old multithreaded code took 24.076 seconds [*] - Proxy resolving using the new code took 8.011 seconds [*] - Without a PAC script, resolving the DNS took 8.003 seconds The new proxy resolving times (8.011s) are much closer to the theoretical best (8.003s)! [*] The PAC script I used for the test was a fairly complex script 20kb (a version of google's corp PAC script modified to always call dnsResolve(host)). I will be adding histograms in a follow-up CL, to measure how often requests need to be restarted, or fall-back to synchronous mode. BUG=119151 Review URL: https://codereview.chromium.org/11885009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@179714 0039d316-1c4b-4281-b951-d872f2087c98
* Remove dead code around ChromeProxyConfigService creation.pauljensen@chromium.org2013-01-181-3/+2
| | | | | | | | IOThread::pref_proxy_config_tracker_ has always been explicitly initialized so the conditions checking whether it's initialized can be eliminated. Review URL: https://chromiumcodereview.appspot.com/11886090 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@177583 0039d316-1c4b-4281-b951-d872f2087c98
* Fix iOS build for XCode 4.6.justincohen@google.com2013-01-081-1/+1
| | | | | | | | | | | | The new clang has some bug fixes and is slightly pickier about unused variables. BUG=NONE TBR=mark Review URL: https://chromiumcodereview.appspot.com/11635050 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@175587 0039d316-1c4b-4281-b951-d872f2087c98
* Renaming instances of "flimflam" with "shill", now that we're only using shill.gspencer@chromium.org2012-09-071-1/+1
| | | | | | | | | | | | | | | Does not rename things from the flimflam:: namespace in service_constants.h: that will be saved for a later pass. I think this counts as refactoring, so I'm TBR'ing the OWNERS checks. TBR=zelidrag@chromium.org,glotov@chromium.org BUG=chromium:146616 TEST=built and ran Review URL: https://chromiumcodereview.appspot.com/10915106 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@155477 0039d316-1c4b-4281-b951-d872f2087c98
* Add iOS support to ProxyServicedroger@chromium.org2012-09-041-0/+8
| | | | | | | | | | | | | | The iOS implementation is similar to the Mac implementation with the following differences: - the SCDynamicStore API does not exist on iOS, thus configuration changes are only detected by polling - several features are not supported. BUG=145954 Review URL: https://chromiumcodereview.appspot.com/10882010 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@154758 0039d316-1c4b-4281-b951-d872f2087c98
* net: Add a new target 'net_with_v8'.tfarina@chromium.org2012-08-311-1/+2
| | | | | | | | | | | | | | | | This target depends on v8 as the name implies, and thus we can remove the v8 dependency from net library itself. This will benefit views package, because views does not need anything from v8, but since it depends on ui_base it needs things from net too. BUG=137800 R=eroman@chromium.org TBR=ben@chromium.org Review URL: https://chromiumcodereview.appspot.com/10874077 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@154434 0039d316-1c4b-4281-b951-d872f2087c98
* Use SingleThreadTaskRunner instead of MessageLoopProxy in ProxyConfigService.sergeyu@chromium.org2012-05-241-2/+2
| | | | | | | | MessageLoopProxy is not usable in plugin, and so it's not possible to use ProxyConfigService in plugins if it uses MessageLoopProxy. Review URL: https://chromiumcodereview.appspot.com/10414061 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@138751 0039d316-1c4b-4281-b951-d872f2087c98
* Fix race condition in ChromeProxyConfigServicebattre@chromium.org2011-12-181-2/+3
| | | | | | | | | | | | | | | | | The ChromeProxyConfigService was initialized to CONFIG_UNSET (i.e. effectively a fallback to the system configuration) until the UI thread reported the preference stored in the PrefService. This created a race condition during startup where restored tabs could send requests while the ChromeProxyConfigService was not configured with the values from the PrefService, yet. BUG=107326 TEST=no Review URL: http://codereview.chromium.org/8951012 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@114942 0039d316-1c4b-4281-b951-d872f2087c98
* Remove BrowserThread::UnsafeGetBrowserThread, add UnsafeGetMessageLoopForThread.joi@chromium.org2011-12-071-2/+2
| | | | | | | | | | | | | | This also removes several accessors on BrowserProcess that are no longer used. I wanted to remove all retrieval of MessageLoop objects via BrowserThread, but this proved harder than it looked, because several net:: classes use MessageLoop and have fairly deep assumptions that it is a real MessageLoop, e.g. they use MessageLoopForIO with its IO observers and so forth. Therefore, we now have UnsafeGetMessageLoopForThread but UnsafeGetBrowserThread is gone. TBR=abodenha@chromium.org BUG=98716 Review URL: http://codereview.chromium.org/8769013 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@113377 0039d316-1c4b-4281-b951-d872f2087c98
* Remove IOThread::message_loop().joi@chromium.org2011-12-021-2/+2
| | | | | | | | | | | | | | | | | Instead introduce BrowserThread::UnsafeGetMessageLoop which is used in a couple of places. This will be removed in a follow-up change. I could have used UnsafeGetBrowserThread(id)->message_loop() but this is even easier to search for. Also, remove a couple of BrowserProcess accessors that aren't used by anybody, and that were using UnsafeGetBrowserThread. TBR=battre@chromium.org BUG=98716 Review URL: http://codereview.chromium.org/8775014 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@112697 0039d316-1c4b-4281-b951-d872f2087c98
* Switch to IWYU for files that previously were getting a bunch ofjoi@chromium.org2011-12-011-0/+1
| | | | | | | | | | | header files via io_thread.h or browser_thread.h TBR=owners (previously approved on codereview 8477004) BUG=98716 Review URL: http://codereview.chromium.org/8746023 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@112455 0039d316-1c4b-4281-b951-d872f2087c98
* redesign and reimplement proxy config service and tracker, revise proxy ui ↵kuan@chromium.org2011-11-041-13/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | on cros * original plan was to revise proxy ui on cros for all proxy sources and network types, refer to bug rpt 21219 for ui details * redesign and reimplement PrefProxyConfigTracker and PrefProxyConfigService by switching the inter-dependencies between the two and renaming the latter - PrefProxyConfigService used to observe PrefProxyConfigTracker and retrieve new prefs proxy from the latter whenever the former gets notification of proxy change from prefs or delegate service to determine effective proxy config. Now, PrefProxyConfigTracker pushes new prefs proxy to the renamed ChromeProxyConfigService on the IO thread; the latter then uses it and proxy from delegate service to determine effective proxy config. - remove all thread-switching in PrefProxyConfigTracker which now lives and runs on UI thread, except for when it pushes proxy config to ChromeProxyConfigService on IO thread - enhances and moves ConfigState definition to namespace ProxyPrefs to indicate source of proxy config (policy, extension, other-precede, system, fallback) so that PrefProxyConfigTracker, ChromeProxyConfigService and chromeos::ProxyConfigServiceImpl can acccess it - extract code for deciding effective proxy config from PrefProxyConfigService into static PrefProxyConfigTracker method to be shared by all classes * re-design and re-implement chromeos::ProxyConfigServiceImpl - this now extends PrefProxyConfigTracker to act as a special of "prefs", handles all proxy changes from network and prefs notifications and uses PrefProxyConfigTracker to push effective proxy to ChromeProxyConfigService and hence to network stack - remove wrapper chromeos::ProxyConfigService - this is the authority on cros, and ChromeProxyConfigService does not have a delegat service. - provide proxy config to ui for all proxy sources: policy, extension, network or recommended (in order of precedence), also indicates if proxy is user-modifiable - handle user profile changes to use correct PrefProxyConfigTracker * modify CoreOptionsHandler and CoreChromeosOptionsHandler to implement dynamic monitoring of prefs::kProxy and on-the-fly ui changes of affected use-shared-proxies user pref * modify ui native code, html, css and javascript for internet options and proxy pages to show yellow banner with different messages (same banner as options page when there's policy), en/dis-able ui fields, set current user profile in backend * modify network dropdown menu to always show proxy settings menu item as long as there's a network * modify automation tests, PrefProxyConfigTracker and ProxyConfigSerivceImpl unittests to handle redesign, fix unittests that fail due to redesign BUG=chromium-os:20679,chromium-os:21219 TEST=verify per bugs rpts Review URL: http://codereview.chromium.org/8102019 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@108616 0039d316-1c4b-4281-b951-d872f2087c98
* Move BrowserThread to content namespace.joi@chromium.org2011-11-021-0/+2
| | | | | | | | | TBR=owners BUG=98716 Review URL: http://codereview.chromium.org/8437002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@108270 0039d316-1c4b-4281-b951-d872f2087c98
* Split BrowserThread into public API and private implementation, step 1.joi@chromium.org2011-10-281-2/+2
| | | | | | | | | | | | | | | | | | | | | Only content/ now has the ability to create BrowserThread objects, with the exception that tests can create the content::TestBrowserThread subclass, and (temporarily) code in chrome/ can create the DeprecatedBrowserThread subclass. A follow-up change will make content/ take care of its own thread creation, remove DeprecatedBrowserThread, and move all state and non-trivial constructors from BrowserThread down to BrowserThreadImpl. Also moved BrowserProcessSubThread into content/ namespace. As part of follow-up cleanup, chrome/ will stop using this class. BUG=98716 TEST=existing Review URL: http://codereview.chromium.org/8392042 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107718 0039d316-1c4b-4281-b951-d872f2087c98
* Rework LibcrosService using our D-Bus library.satorux@chromium.org2011-09-171-8/+0
| | | | | | | | | | | | | | | | | | | | | Also introduce DBusThreadManager, that manages the D-Bus thread, and D-Bus clients using the thread. cros_dbus_service.cc and proxy_resolution_service_provider.cc are based on libcros_service_library.cc. The basic logic is kept as before. The major changes are: - Get rid of all libcros function calls (ex. StartLibCrosService). - Export "ResolveProxy" D-Bus method from Chrome, instead of libcros. - CrosDBusService is now managed by DBusThreadManager, instead of CrosLibrary. - Reduce use of nested class per the C++ style guide. - Now unit tested: libcros_service_unittest.cc BUG=chromium-os:18904 TEST=on the device, change the proxy config to use http://proxyconfig.corp.google.com/wpad.dat, run /opt/google/chrome/chromeos/libcros_service_tester (installed by USE=install_tests gmerge libcros), and confirm the libcros service works as before. Review URL: http://codereview.chromium.org/7819012 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@101640 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 89629 - Revert 89486 - Revert 87047 - Revert 86422 - Make DHCP WPAD ↵cevans@chromium.org2011-06-201-2/+2
| | | | | | | | | | | | | | | | | | | | | on by default. Reason: Turning back on for trunk to collect data as performance worries are addressed. BUG=18575,84047 TEST=Run Chrome on Windows without any flags. Enable auto-detect in proxy configuration. Net log should show attempts to auto-detect via DHCP. Review URL: http://codereview.chromium.org/7167016 TBR=joi@chromium.org NOTE: I'll roll it back in if it turns out this wasn't the problem. Review URL: http://codereview.chromium.org/7200025 TBR=cevans@chromium.org Review URL: http://codereview.chromium.org/7204024 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@89633 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 89486 - Revert 87047 - Revert 86422 - Make DHCP WPAD on by default.cevans@chromium.org2011-06-191-2/+2
| | | | | | | | | | | | | | | | Reason: Turning back on for trunk to collect data as performance worries are addressed. BUG=18575,84047 TEST=Run Chrome on Windows without any flags. Enable auto-detect in proxy configuration. Net log should show attempts to auto-detect via DHCP. Review URL: http://codereview.chromium.org/7167016 TBR=joi@chromium.org NOTE: I'll roll it back in if it turns out this wasn't the problem. Review URL: http://codereview.chromium.org/7200025 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@89629 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 87047 - Revert 86422 - Make DHCP WPAD on by default.joi@chromium.org2011-06-171-2/+2
| | | | | | | | | | | Reason: Turning back on for trunk to collect data as performance worries are addressed. BUG=18575,84047 TEST=Run Chrome on Windows without any flags. Enable auto-detect in proxy configuration. Net log should show attempts to auto-detect via DHCP. Review URL: http://codereview.chromium.org/7167016 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@89486 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 86422 - Make DHCP WPAD on by default.joi@chromium.org2011-05-271-2/+2
| | | | | | | | | | | Reason: Turning off for M13 branch based on some concerns from user experience metrics. Will re-enable after M13 branch point. BUG=18575,84047 TEST=Run Chrome on Windows without any flags. Enable auto-detect in proxy configuration. Net log should show attempts to auto-detect via DHCP. Review URL: http://codereview.chromium.org/7082004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@87047 0039d316-1c4b-4281-b951-d872f2087c98
* Make DHCP WPAD on by default.joi@chromium.org2011-05-241-2/+2
| | | | | | | | | BUG=18575 TEST=Run Chrome on Windows without any flags. Enable auto-detect in proxy configuration. Net log should show attempts to auto-detect via DHCP. Review URL: http://codereview.chromium.org/7034035 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@86422 0039d316-1c4b-4281-b951-d872f2087c98
* Adds support for the DHCP portion of the WPAD (proxy auto-discovery) protocol.joi@chromium.org2011-05-171-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is Windows-only for now, and is disabled by default. Start Chrome with the flag --enable-dhcp-wpad to enable the feature. See discussion in comment on DhcpProxyScriptFetcherFactory for why this needs to be done in a per-platform way rather than cross-platform. The code is factored so that adding other platform implementations will be straight forward. Most of the implementation is stand-alone and extends the ScriptProxyFetcher class hierarchy (and makes its interface slightly more generic). The integration point into existing code is in InitProxyResolver, which previously handled fallback from DNS auto-detect to custom PAC URL and now does fallback from DHCP to DNS to custom PAC URL. BUG=18575 TEST=net_unittests has good coverage for the new and changed code, but manual tests on a network with a PAC URL configured in DHCP are also needed. Original commit r85646. Reverted (test failures on some release bots) r85648. Will reland with fix. Review URL: http://codereview.chromium.org/6831025 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@85661 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 85646 - Adds support for the DHCP portion of the WPAD (proxy ↵joi@chromium.org2011-05-171-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | auto-discovery) protocol. This is Windows-only for now, and is disabled by default. Start Chrome with the flag --enable-dhcp-wpad to enable the feature. See discussion in comment on DhcpProxyScriptFetcherFactory for why this needs to be done in a per-platform way rather than cross-platform. The code is factored so that adding other platform implementations will be straight forward. Most of the implementation is stand-alone and extends the ScriptProxyFetcher class hierarchy (and makes its interface slightly more generic). The integration point into existing code is in InitProxyResolver, which previously handled fallback from DNS auto-detect to custom PAC URL and now does fallback from DHCP to DNS to custom PAC URL. BUG=18575 TEST=net_unittests has good coverage for the new and changed code, but manual tests on a network with a PAC URL configured in DHCP are also needed. Review URL: http://codereview.chromium.org/6831025 TBR=joi@chromium.org Review URL: http://codereview.chromium.org/7019015 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@85648 0039d316-1c4b-4281-b951-d872f2087c98
* Adds support for the DHCP portion of the WPAD (proxy auto-discovery) protocol.joi@chromium.org2011-05-171-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | This is Windows-only for now, and is disabled by default. Start Chrome with the flag --enable-dhcp-wpad to enable the feature. See discussion in comment on DhcpProxyScriptFetcherFactory for why this needs to be done in a per-platform way rather than cross-platform. The code is factored so that adding other platform implementations will be straight forward. Most of the implementation is stand-alone and extends the ScriptProxyFetcher class hierarchy (and makes its interface slightly more generic). The integration point into existing code is in InitProxyResolver, which previously handled fallback from DNS auto-detect to custom PAC URL and now does fallback from DHCP to DNS to custom PAC URL. BUG=18575 TEST=net_unittests has good coverage for the new and changed code, but manual tests on a network with a PAC URL configured in DHCP are also needed. Review URL: http://codereview.chromium.org/6831025 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@85646 0039d316-1c4b-4281-b951-d872f2087c98
* Add a method for PAC script errors to the network delegate.jochen@chromium.org2011-05-031-1/+2
| | | | | | | | | | | Also add a wrapper class to avoid passing around raw NULL pointers, and a bridge so I can invoke the method from other than the IO thread BUG=48930 TEST=net unittests Review URL: http://codereview.chromium.org/6822026 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@83881 0039d316-1c4b-4281-b951-d872f2087c98
* Stop refcounting ProxyService.willchan@chromium.org2011-04-271-0/+1
| | | | | | | | | BUG=none TEST=none Review URL: http://codereview.chromium.org/6873096 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@83222 0039d316-1c4b-4281-b951-d872f2087c98
* chromeos: fix crash when freeing ProxyService in LibCrosServiecLibrary.kuan@chromium.org2011-03-161-2/+1
| | | | | | | | | | | | | It was wrong to store ProxyService in a singleton, because the former must live and die on the IO thread, whereas a singleton dies on the UI thread. Instead, get access to ProxyService as and when proxy resolution service is requested. BUG=chromium-os:13077 TEST=verify crash doesn't happen. Review URL: http://codereview.chromium.org/6677046 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@78436 0039d316-1c4b-4281-b951-d872f2087c98
* This is an extension of http://codereview.chromium.org/6280018 that provides ↵battre@chromium.org2011-03-161-0/+107
| | | | | | | | | | | | | a proxy configuration which respects command line parameters and policies This was committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=78228, iyengar asked to commit again after fixing trunk. BUG=67232,70732 TEST=Start chrome, observe two PROXY_CONFIG_CHANGED events in about:net-internals (if you are on a corporate network with PAC configurations), observe that everything behaves as usual. In particular the https://www.google.com/searchdomaincheck?format=domain&type=chrome request should not fail as it uses the new system URLRequestContext. Review URL: http://codereview.chromium.org/6292017 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@78362 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 78228 - Extended: Add "system" URLRequestContext (not ready for use!)jam@chromium.org2011-03-151-107/+0
| | | | | | | | | | | | | | This is an extension of http://codereview.chromium.org/6280018 that provides a proxy configuration which respects command line parameters and policies BUG=67232,70732 TEST=Start chrome, observe two PROXY_CONFIG_CHANGED events in about:net-internals (if you are on a corporate network with PAC configurations), observe that everything behaves as usual. In particular the https://www.google.com/searchdomaincheck?format=domain&type=chrome request should not fail as it uses the new system URLRequestContext. Review URL: http://codereview.chromium.org/6292017 TBR=battre@chromium.org Review URL: http://codereview.chromium.org/6693023 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@78240 0039d316-1c4b-4281-b951-d872f2087c98
* Extended: Add "system" URLRequestContext (not ready for use!)battre@chromium.org2011-03-151-0/+107
This is an extension of http://codereview.chromium.org/6280018 that provides a proxy configuration which respects command line parameters and policies BUG=67232,70732 TEST=Start chrome, observe two PROXY_CONFIG_CHANGED events in about:net-internals (if you are on a corporate network with PAC configurations), observe that everything behaves as usual. In particular the https://www.google.com/searchdomaincheck?format=domain&type=chrome request should not fail as it uses the new system URLRequestContext. Review URL: http://codereview.chromium.org/6292017 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@78228 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-05-18 06:40:02 +0000