Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2978443002:
Make ProfileIOData use URLRequestContextBuilder (Closed)
|
Created:
3 years, 5 months ago by mmenke Modified:
3 years, 5 months ago Reviewers:
Randy Smith (Not in Mondays) CC:
chromium-reviews, cbentzel+watch_chromium.org, net-reviews_chromium.org Target Ref:
refs/heads/master Project:
chromium Visibility:
Public. |
DescriptionMake ProfileIOData use URLRequestContextBuilder
BUG=734199
Review-Url: https://codereview.chromium.org/2978443002
Cr-Commit-Position: refs/heads/master@{#487590}
Committed: https://chromium.googlesource.com/chromium/src/+/189ddf60b2f4034a2ab6efb16e22ea389b2b779f
Patch Set 1 #Patch Set 2 : Merge, flesh out #Patch Set 3 : Fixes... #Patch Set 4 : Oops #Patch Set 5 : More fixes. #Patch Set 6 : Fix protocol_handler_interceptor #Patch Set 7 : Fix ChromeOS, extension throttles, merge #
Total comments: 3
Patch Set 8 : Merge #
Total comments: 20
Patch Set 9 : Response to comments #Patch Set 10 : Fix merge #Patch Set 11 : ? #
Total comments: 2
Patch Set 12 : Response to comments #Dependent Patchsets: Messages
Total messages: 75 (63 generated)
The CQ bit was checked by [email protected] to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by [email protected]
Dry run: Try jobs failed on following builders: ios-simulator on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...)
The CQ bit was checked by [email protected] to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by [email protected]
Dry run: Try jobs failed on following builders: android_cronet on master.tryserver.chromium.android (JOB_FAILED, https://build.chromium.org/p/tryserver.chromium.android/builders/android_cron...)
Patchset #2 (id:20001) has been deleted
The CQ bit was checked by [email protected] to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by [email protected]
Dry run: Try jobs failed on following builders: android_compile_dbg on master.tryserver.chromium.android (JOB_FAILED, https://build.chromium.org/p/tryserver.chromium.android/builders/android_comp...)
The CQ bit was checked by [email protected] to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was checked by [email protected] to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by [email protected]
Dry run: Try jobs failed on following builders: mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...) mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)
The CQ bit was checked by [email protected] to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Patchset #4 (id:80001) has been deleted
Patchset #3 (id:60001) has been deleted
The CQ bit was checked by [email protected] to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was checked by [email protected] to run a CQ dry run
Patchset #5 (id:140001) has been deleted
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by [email protected]
Dry run: Try jobs failed on following builders: linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED, https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)
The CQ bit was checked by [email protected] to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Patchset #6 (id:180001) has been deleted
The CQ bit was unchecked by [email protected]
Dry run: Try jobs failed on following builders: linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
The CQ bit was checked by [email protected] to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Patchset #7 (id:210001) has been deleted
[email protected] changed reviewers: + [email protected]
The IOThread version of this broke 4 (?) things while managing to pass the CQ. Let's see if I can manage to break even more stuff this time! I'm not sure if I want to deal with the app request contexts before or after I start adding configuration to the network service. Before means I can create a URLRequestContextBuilder for it, which is more like the current code, and then migrate it over piece-by-piece as I migrate everything else, but it will require maybe an extra week or two. After means the switch will be more abrupt, but less effort. https://codereview.chromium.org/2978443002/diff/230001/chrome/browser/profile... File chrome/browser/profiles/profile_io_data.cc (right): https://codereview.chromium.org/2978443002/diff/230001/chrome/browser/profile... chrome/browser/profiles/profile_io_data.cc:1150: } This logic was moved from ProfileIOData::CreateHttpNetworkSession, which had been called by the subclasses, to the parent class.
The CQ bit was unchecked by [email protected]
Dry run: Try jobs failed on following builders: android_n5x_swarming_rel on master.tryserver.chromium.android (JOB_FAILED, https://build.chromium.org/p/tryserver.chromium.android/builders/android_n5x_...)
Description was changed from ========== Make ProfileIOData use URLRequestContextBuilder BUG= ========== to ========== Make ProfileIOData use URLRequestContextBuilder BUG=734199 ==========
The CQ bit was checked by [email protected] to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
[rdsmith]: Just want to make sure this one's on your radar. If there's any CL where it's worth taking your time, though, it's certainly this one.
On 2017/07/14 16:30:05, mmenke wrote: > [rdsmith]: Just want to make sure this one's on your radar. If there's any CL > where it's worth taking your time, though, it's certainly this one. Yep. I did a first pass through to try to wrap my brain around it yesterday, and it's top of my list for today. I should have feedback for you by EOD.
On 2017/07/14 17:02:56, Randy Smith (Not in Mondays) wrote: > On 2017/07/14 16:30:05, mmenke wrote: > > [rdsmith]: Just want to make sure this one's on your radar. If there's any > CL > > where it's worth taking your time, though, it's certainly this one. > > Yep. I did a first pass through to try to wrap my brain around it yesterday, > and it's top of my list for today. I should have feedback for you by EOD. Great, thanks! Just FYI, I'm certainly not landing this until after branch.
The CQ bit was unchecked by [email protected]
Dry run: This issue passed the CQ dry run.
First round. I'm not *completely* done in nailing down everything, but it's EOD on Friday and I think it'll be more useful for me to give you what I've got than waiting (especially as I'm raising the possibility of a supporting CL). https://codereview.chromium.org/2978443002/diff/230001/net/url_request/url_re... File net/url_request/url_request_context_builder.cc (right): https://codereview.chromium.org/2978443002/diff/230001/net/url_request/url_re... net/url_request/url_request_context_builder.cc:288: void URLRequestContextBuilder::SetCertVerifier( nit, not actionable: I'm a bit uncomfortable with the naming inconsistency in this class, where methods of similar complexity have both camelcase and all lower names. Not your problem, at least in this CL, but I wanted to call it out. https://codereview.chromium.org/2978443002/diff/250001/chrome/browser/profile... File chrome/browser/profiles/profile_impl_io_data.cc (right): https://codereview.chromium.org/2978443002/diff/250001/chrome/browser/profile... chrome/browser/profiles/profile_impl_io_data.cc:115: // Returns the BackendType that the disk cache should use. Once all Stick a TODO(mmenke) at the beginning of the second sentence? https://codereview.chromium.org/2978443002/diff/250001/chrome/browser/profile... chrome/browser/profiles/profile_impl_io_data.cc:789: std::unique_ptr<net::ReportingService> nit, suggestion: TODO for removal when app contexts are converted to builder? https://codereview.chromium.org/2978443002/diff/250001/chrome/browser/profile... File chrome/browser/profiles/profile_impl_io_data.h (right): https://codereview.chromium.org/2978443002/diff/250001/chrome/browser/profile... chrome/browser/profiles/profile_impl_io_data.h:38: class ProfileImplIOData : public ProfileIOData { It's probably completely unreasonable for me to nourish a hope that somewhere in all this we can regularize the naming of this class hierarchy? :-} . The inconsistency keeps picking at me. Of course, the obvious way to do it is OffTheRecordProfileIOData -> OffTheRecordProfileImplIOData, which is probably just gratuitous, but it still has some appeal. https://codereview.chromium.org/2978443002/diff/250001/chrome/browser/profile... chrome/browser/profiles/profile_impl_io_data.h:173: ProfileParams* profile_params) const override; What's the rationale for the creation of this routine? You're clearly delaying setting the extensions context creation until after some dependency, but I'm not yet seeing the dependency. https://codereview.chromium.org/2978443002/diff/250001/chrome/browser/profile... File chrome/browser/profiles/profile_io_data.cc (right): https://codereview.chromium.org/2978443002/diff/250001/chrome/browser/profile... chrome/browser/profiles/profile_io_data.cc:1072: &builder, std::move(profile_params_->proxy_config_service)); I'm busting my brain trying to confirm that this transformation is correct; ProxyServiceFactory::CreateProxyService and IOThread::SetUpProxyConfigService *look* similar, but they call different subroutines and I'm not finding it easy to convince myself that they're actually identical. Feel free to push back and I'll look at in in a future round of review, but what would you think of a separate CL that actually unified the code along those two paths that this CL is dependent on? If they are really doing the same thing, the code shouldn't be duplicated, should it? Or if it is, it should be duplicated within the same class in a way that makes it clear that it's a creation -> builder transformation? https://codereview.chromium.org/2978443002/diff/250001/chrome/browser/profile... chrome/browser/profiles/profile_io_data.cc:1213: ProfileIOData::SetUpJobFactoryDefaults( nit, suggestion: TODO to remove after app contexts transferred? https://codereview.chromium.org/2978443002/diff/250001/net/url_request/url_re... File net/url_request/url_request_context_builder.cc (right): https://codereview.chromium.org/2978443002/diff/250001/net/url_request/url_re... net/url_request/url_request_context_builder.cc:559: // first doesn't include in memory, so may require some work. This looks to me as if it could be a simplification of the cache interface, allowing backend_type to vary between disk and memory. But it should probably be driven from that side; maybe toss a note at Maks? https://codereview.chromium.org/2978443002/diff/250001/net/url_request/url_re... File net/url_request/url_request_context_builder.h (right): https://codereview.chromium.org/2978443002/diff/250001/net/url_request/url_re... net/url_request/url_request_context_builder.h:183: HttpUserAgentSettings* shared_http_user_agent_settings); I can't imagine it will surprise you that I'm somewhat offended by the existence of the "set_*/set_shared_*" distinction in this class :-} (though if you are surprised, let me know and I'll expand on my discomfort). I get why you're doing it, but I'd love to see it go away at some point. I'm reaching for pushing things in this category either into a truly shared global object for the network stack, where we can audit privacy and security issues (aren't there privacy issues with sharing a host resolver between profiles?) or just having them separately owned. This isn't something reasonable to do in this CL, but I'd like to make sure we don't lose track--could you file a bug and reference it from the code? Also, just because I'm OCD, could you put a "consumer must guarantee that this object outlives the created URLRequestContext"? (Applies to all "set_shared*" methods.) It seems obvious, but it's also vital, and in balance I think that makes it worth saying. (Separately I think the dependency on objects owned in the SystemURLRequestContext implies a shutdown ordering requirement--is that documented anywhere? Not new in this CL, obviously; it just looks like a spike that someone could impale themselves on at some point.)
The CQ bit was checked by [email protected] to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Thanks for the review! https://codereview.chromium.org/2978443002/diff/230001/net/url_request/url_re... File net/url_request/url_request_context_builder.cc (right): https://codereview.chromium.org/2978443002/diff/230001/net/url_request/url_re... net/url_request/url_request_context_builder.cc:288: void URLRequestContextBuilder::SetCertVerifier( On 2017/07/14 21:37:09, Randy Smith (Not in Mondays) wrote: > nit, not actionable: I'm a bit uncomfortable with the naming inconsistency in > this class, where methods of similar complexity have both camelcase and all > lower names. Not your problem, at least in this CL, but I wanted to call it > out. Yea, you're right. I think it's worth cleaning up at some point, but I want a better idea of what we're going to need to keep before I bother. We're also inconsistent about whether or not we inline methods that just call std::move, which we should also resolve. https://codereview.chromium.org/2978443002/diff/250001/chrome/browser/profile... File chrome/browser/profiles/profile_impl_io_data.cc (right): https://codereview.chromium.org/2978443002/diff/250001/chrome/browser/profile... chrome/browser/profiles/profile_impl_io_data.cc:115: // Returns the BackendType that the disk cache should use. Once all On 2017/07/14 21:37:09, Randy Smith (Not in Mondays) wrote: > Stick a TODO(mmenke) at the beginning of the second sentence? Done. Not sure why I didn't do that initially on all of these. https://codereview.chromium.org/2978443002/diff/250001/chrome/browser/profile... chrome/browser/profiles/profile_impl_io_data.cc:789: std::unique_ptr<net::ReportingService> On 2017/07/14 21:37:09, Randy Smith (Not in Mondays) wrote: > nit, suggestion: TODO for removal when app contexts are converted to builder? There's already a TODO in the header. https://codereview.chromium.org/2978443002/diff/250001/chrome/browser/profile... File chrome/browser/profiles/profile_impl_io_data.h (right): https://codereview.chromium.org/2978443002/diff/250001/chrome/browser/profile... chrome/browser/profiles/profile_impl_io_data.h:38: class ProfileImplIOData : public ProfileIOData { On 2017/07/14 21:37:09, Randy Smith (Not in Mondays) wrote: > It's probably completely unreasonable for me to nourish a hope that somewhere in > all this we can regularize the naming of this class hierarchy? :-} . The > inconsistency keeps picking at me. Of course, the obvious way to do it is > OffTheRecordProfileIOData -> OffTheRecordProfileImplIOData, which is probably > just gratuitous, but it still has some appeal. I want to remove these classes in favor of BrowserContextKeyedServices, and merge them into one class. Which I think will address that concern (in about 5 years). :) https://codereview.chromium.org/2978443002/diff/250001/chrome/browser/profile... chrome/browser/profiles/profile_impl_io_data.h:173: ProfileParams* profile_params) const override; On 2017/07/14 21:37:09, Randy Smith (Not in Mondays) wrote: > What's the rationale for the creation of this routine? You're clearly delaying > setting the extensions context creation until after some dependency, but I'm not > yet seeing the dependency. It's not the extensions, but the media request context that's the problem (Which requires the main request context be built, first). https://codereview.chromium.org/2978443002/diff/250001/chrome/browser/profile... File chrome/browser/profiles/profile_io_data.cc (right): https://codereview.chromium.org/2978443002/diff/250001/chrome/browser/profile... chrome/browser/profiles/profile_io_data.cc:1072: &builder, std::move(profile_params_->proxy_config_service)); On 2017/07/14 21:37:09, Randy Smith (Not in Mondays) wrote: > I'm busting my brain trying to confirm that this transformation is correct; > ProxyServiceFactory::CreateProxyService and IOThread::SetUpProxyConfigService > *look* similar, but they call different subroutines and I'm not finding it easy > to convince myself that they're actually identical. Feel free to push back and > I'll look at in in a future round of review, but what would you think of a > separate CL that actually unified the code along those two paths that this CL is > dependent on? If they are really doing the same thing, the code shouldn't be > duplicated, should it? Or if it is, it should be duplicated within the same > class in a way that makes it clear that it's a creation -> builder > transformation? The problem is IOThread::SetUpProxyConfigService works on a URLRequestContextBuilder, and ProxyServiceFactory::CreateProxyService works on a URLRequestContext. So I can't unify them in another CL. I also can't use ProxyServiceFactory::CreateProxyService after using the new URLRequestContextBuilder to create a context, because the proxy is injected into the HttpNetworkSession. I could inline the new logic here, but it would be the same transformation that I'm doing to merge the two methods. Note that IOThread used ProxyServiceFactory::CreateProxyService before I switched it over to the new code (That's not proof that this is correct, but it does point towards comparing the old IOThread code to the old ProfileIOData code. If they're the same, then one transformation being correct implies the other is as well). I'm open to other ways to do this, but I don't see one, unless I inject a temporary callback into URLRequestContextBuilder to set up the proxy service, given the URLRequestContext being built, or subclass it in this file (Since it already has a virtual method for that). https://codereview.chromium.org/2978443002/diff/250001/chrome/browser/profile... chrome/browser/profiles/profile_io_data.cc:1213: ProfileIOData::SetUpJobFactoryDefaults( On 2017/07/14 21:37:09, Randy Smith (Not in Mondays) wrote: > nit, suggestion: TODO to remove after app contexts transferred? Done (Though added to the header). https://codereview.chromium.org/2978443002/diff/250001/net/url_request/url_re... File net/url_request/url_request_context_builder.cc (right): https://codereview.chromium.org/2978443002/diff/250001/net/url_request/url_re... net/url_request/url_request_context_builder.cc:559: // first doesn't include in memory, so may require some work. On 2017/07/14 21:37:09, Randy Smith (Not in Mondays) wrote: > This looks to me as if it could be a simplification of the cache interface, > allowing backend_type to vary between disk and memory. But it should probably > be driven from that side; maybe toss a note at Maks? Not a big fan of just throwing bugs at people. I may get to it eventually myself. I agree that it's worth cleaning up. Currently in-memory is a "CacheType" and not a "BackendType", which is weird - the other BackendTypes correspond to different cache implementations, while the other CacheTypes refer to what it's used for. https://codereview.chromium.org/2978443002/diff/250001/net/url_request/url_re... File net/url_request/url_request_context_builder.h (right): https://codereview.chromium.org/2978443002/diff/250001/net/url_request/url_re... net/url_request/url_request_context_builder.h:183: HttpUserAgentSettings* shared_http_user_agent_settings); On 2017/07/14 21:37:09, Randy Smith (Not in Mondays) wrote: > I can't imagine it will surprise you that I'm somewhat offended by the existence > of the "set_*/set_shared_*" distinction in this class :-} (though if you are > surprised, let me know and I'll expand on my discomfort). I get why you're > doing it, but I'd love to see it go away at some point. I'm reaching for > pushing things in this category either into a truly shared global object for the > network stack, where we can audit privacy and security issues (aren't there > privacy issues with sharing a host resolver between profiles?) or just having > them separately owned. > > This isn't something reasonable to do in this CL, but I'd like to make sure we > don't lose track--could you file a bug and reference it from the code? Much of this CL is adding technical debt that will hopefully be reasonable to clean up after we switch configuration over to the NetworkContext. I have no intention of cleaning this stuff up while things are still configured by ProfileIOData directly touching the URLRequestContextBuilder. I want to configure most everything through NetworkContext, which will lets us clean most of these up, and then switch the App request contexts over to a network context, resulting in duplicating a ton of objects, in the uncommon case where we have App request contexts. We could move AppRequestContexts over first, and then clean these up by duplicating a ton of stuff using the current ProfileIOData code, but that seems like a lot more work, since we'll want to switch over to having everything go through NetworkContext, anyways (i.e., we'd need to set up UserAgentSettings objects watching prefs on a per-URLRequestContex basis, basically creating a LazyParams object for each AppRequestContext). Anyhow, filed a bug, bug skeptical of the utility of that, given that the number of open network bugs on the tracker is increasing monotonically, and eroman seems to be the only person who occasionally takes on random code health bugs. :) > Also, just because I'm OCD, could you put a "consumer must guarantee that this > object outlives the created URLRequestContext"? (Applies to all "set_shared*" > methods.) It seems obvious, but it's also vital, and in balance I think that > makes it worth saying. Done. > (Separately I think the dependency on objects owned in the > SystemURLRequestContext implies a shutdown ordering requirement--is that > documented anywhere? Not new in this CL, obviously; it just looks like a spike > that someone could impale themselves on at some point.) ProfilIOData talks about it a bit, but the whole thing is rather a mess. Given that I think we should not L-G-T-M anything that adds new objects to the URLRequestContext, unless set up sanely through the builder, I'm not sure about the utility of yet more documentation for stuff I'm actively trying to get rid of, and that won't exist in the Brave New NetworkService World.
The CQ bit was unchecked by [email protected]
Dry run: Try jobs failed on following builders: ios-simulator on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...)
The CQ bit was checked by [email protected] to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by [email protected]
Dry run: This issue passed the CQ dry run.
So LGTM--I'll assume you have more context than I for what the right thing is to do WRT the apparent minor change in behavior in proxy configuration. But I'd be curious as to the answer to my question about your intentions WRT ProxyServiceFactory. https://codereview.chromium.org/2978443002/diff/250001/chrome/browser/profile... File chrome/browser/profiles/profile_impl_io_data.h (right): https://codereview.chromium.org/2978443002/diff/250001/chrome/browser/profile... chrome/browser/profiles/profile_impl_io_data.h:38: class ProfileImplIOData : public ProfileIOData { On 2017/07/14 22:45:37, mmenke wrote: > On 2017/07/14 21:37:09, Randy Smith (Not in Mondays) wrote: > > It's probably completely unreasonable for me to nourish a hope that somewhere > in > > all this we can regularize the naming of this class hierarchy? :-} . The > > inconsistency keeps picking at me. Of course, the obvious way to do it is > > OffTheRecordProfileIOData -> OffTheRecordProfileImplIOData, which is probably > > just gratuitous, but it still has some appeal. > > I want to remove these classes in favor of BrowserContextKeyedServices, and > merge them into one class. Which I think will address that concern (in about 5 > years). :) Ah, ok then. You ease my mind. (The amusing thing about this is that I'm not even kidding :-}.) https://codereview.chromium.org/2978443002/diff/250001/chrome/browser/profile... File chrome/browser/profiles/profile_io_data.cc (right): https://codereview.chromium.org/2978443002/diff/250001/chrome/browser/profile... chrome/browser/profiles/profile_io_data.cc:1072: &builder, std::move(profile_params_->proxy_config_service)); On 2017/07/14 22:45:37, mmenke wrote: > On 2017/07/14 21:37:09, Randy Smith (Not in Mondays) wrote: > > I'm busting my brain trying to confirm that this transformation is correct; > > ProxyServiceFactory::CreateProxyService and IOThread::SetUpProxyConfigService > > *look* similar, but they call different subroutines and I'm not finding it > easy > > to convince myself that they're actually identical. Feel free to push back > and > > I'll look at in in a future round of review, but what would you think of a > > separate CL that actually unified the code along those two paths that this CL > is > > dependent on? If they are really doing the same thing, the code shouldn't be > > duplicated, should it? Or if it is, it should be duplicated within the same > > class in a way that makes it clear that it's a creation -> builder > > transformation? > > The problem is IOThread::SetUpProxyConfigService works on a > URLRequestContextBuilder, and ProxyServiceFactory::CreateProxyService works on a > URLRequestContext. So I can't unify them in another CL. I also can't use > ProxyServiceFactory::CreateProxyService after using the new > URLRequestContextBuilder to create a context, because the proxy is injected into > the HttpNetworkSession. > > I could inline the new logic here, but it would be the same transformation that > I'm doing to merge the two methods. > > Note that IOThread used ProxyServiceFactory::CreateProxyService before I > switched it over to the new code (That's not proof that this is correct, but it > does point towards comparing the old IOThread code to the old ProfileIOData > code. If they're the same, then one transformation being correct implies the > other is as well). > > I'm open to other ways to do this, but I don't see one, unless I inject a > temporary callback into URLRequestContextBuilder to set up the proxy service, > given the URLRequestContext being built, or subclass it in this file (Since it > already has a virtual method for that). Ok, I pulled on my adult overhauls and sat down and verified the transformation (with one question on behavior, in the new PS). But based on the above, I'm curious as to what your long term plans are. What's going to happen to ProxyServiceFactory? Are you leaving it alone, planning to remove CreateProxyService(), or planning to delete the whole thing? It seems funny to have pretty much the same code in two different places. https://codereview.chromium.org/2978443002/diff/250001/net/url_request/url_re... File net/url_request/url_request_context_builder.h (right): https://codereview.chromium.org/2978443002/diff/250001/net/url_request/url_re... net/url_request/url_request_context_builder.h:183: HttpUserAgentSettings* shared_http_user_agent_settings); On 2017/07/14 22:45:37, mmenke wrote: > On 2017/07/14 21:37:09, Randy Smith (Not in Mondays) wrote: > > I can't imagine it will surprise you that I'm somewhat offended by the > existence > > of the "set_*/set_shared_*" distinction in this class :-} (though if you are > > surprised, let me know and I'll expand on my discomfort). I get why you're > > doing it, but I'd love to see it go away at some point. I'm reaching for > > pushing things in this category either into a truly shared global object for > the > > network stack, where we can audit privacy and security issues (aren't there > > privacy issues with sharing a host resolver between profiles?) or just having > > them separately owned. > > > > This isn't something reasonable to do in this CL, but I'd like to make sure we > > don't lose track--could you file a bug and reference it from the code? > > Much of this CL is adding technical debt that will hopefully be reasonable to > clean up after we switch configuration over to the NetworkContext. I have no > intention of cleaning this stuff up while things are still configured by > ProfileIOData directly touching the URLRequestContextBuilder. I want to > configure most everything through NetworkContext, which will lets us clean most > of these up, and then switch the App request contexts over to a network context, > resulting in duplicating a ton of objects, in the uncommon case where we have > App request contexts. That probably makes sense. My sense is that we're moving away from App request contexts and at some point should take the hit of deleting them, but that's a Chrome level issue. > We could move AppRequestContexts over first, and then clean these up by > duplicating a ton of stuff using the current ProfileIOData code, but that seems > like a lot more work, since we'll want to switch over to having everything go > through NetworkContext, anyways (i.e., we'd need to set up UserAgentSettings > objects watching prefs on a per-URLRequestContex basis, basically creating a > LazyParams object for each AppRequestContext). > > Anyhow, filed a bug, bug skeptical of the utility of that, given that the number > of open network bugs on the tracker is increasing monotonically, and eroman > seems to be the only person who occasionally takes on random code health bugs. > :) Fair enough. Thanks for humoring me. > > Also, just because I'm OCD, could you put a "consumer must guarantee that this > > object outlives the created URLRequestContext"? (Applies to all "set_shared*" > > methods.) It seems obvious, but it's also vital, and in balance I think that > > makes it worth saying. > > Done. > > > (Separately I think the dependency on objects owned in the > > SystemURLRequestContext implies a shutdown ordering requirement--is that > > documented anywhere? Not new in this CL, obviously; it just looks like a > spike > > that someone could impale themselves on at some point.) > > ProfilIOData talks about it a bit, but the whole thing is rather a mess. Given > that I think we should not L-G-T-M anything that adds new objects to the > URLRequestContext, unless set up sanely through the builder, I'm not sure about > the utility of yet more documentation for stuff I'm actively trying to get rid > of, and that won't exist in the Brave New NetworkService World. Ok. https://codereview.chromium.org/2978443002/diff/310001/chrome/browser/io_thre... File chrome/browser/io_thread.cc (right): https://codereview.chromium.org/2978443002/diff/310001/chrome/browser/io_thre... chrome/browser/io_thread.cc:801: LOG(ERROR) << "Cannot use V8 Proxy resolver in single process mode."; So this looks to me like a potential change from the original. IIUC, ProxyServiceFactory::CreateProxyService(), in this fallback case, would log the error as above, would skip the ChromeMojoProxyResolverFactory as below, but would also skip the dhcp_fetcher_factory assignment on ChromeOS. Is there some reason why the kSingleProcess switch couldn't occur on ChromeOS? (I realize that we don't support kSingleProcess, but I don't think we want to break it for ChromeOS unless there's a specific reason?)
The CQ bit was checked by [email protected] to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Thanks for the review! Know this was pretty hairy, appreciate the attention to detail! I'll do a final experimental double-check to make sure the cache and transport security paths are indeed the same before landing. https://codereview.chromium.org/2978443002/diff/250001/chrome/browser/profile... File chrome/browser/profiles/profile_io_data.cc (right): https://codereview.chromium.org/2978443002/diff/250001/chrome/browser/profile... chrome/browser/profiles/profile_io_data.cc:1072: &builder, std::move(profile_params_->proxy_config_service)); On 2017/07/18 18:26:54, Randy Smith (Not in Mondays) wrote: > On 2017/07/14 22:45:37, mmenke wrote: > > On 2017/07/14 21:37:09, Randy Smith (Not in Mondays) wrote: > > > I'm busting my brain trying to confirm that this transformation is correct; > > > ProxyServiceFactory::CreateProxyService and > IOThread::SetUpProxyConfigService > > > *look* similar, but they call different subroutines and I'm not finding it > > easy > > > to convince myself that they're actually identical. Feel free to push back > > and > > > I'll look at in in a future round of review, but what would you think of a > > > separate CL that actually unified the code along those two paths that this > CL > > is > > > dependent on? If they are really doing the same thing, the code shouldn't > be > > > duplicated, should it? Or if it is, it should be duplicated within the same > > > class in a way that makes it clear that it's a creation -> builder > > > transformation? > > > > The problem is IOThread::SetUpProxyConfigService works on a > > URLRequestContextBuilder, and ProxyServiceFactory::CreateProxyService works on > a > > URLRequestContext. So I can't unify them in another CL. I also can't use > > ProxyServiceFactory::CreateProxyService after using the new > > URLRequestContextBuilder to create a context, because the proxy is injected > into > > the HttpNetworkSession. > > > > I could inline the new logic here, but it would be the same transformation > that > > I'm doing to merge the two methods. > > > > Note that IOThread used ProxyServiceFactory::CreateProxyService before I > > switched it over to the new code (That's not proof that this is correct, but > it > > does point towards comparing the old IOThread code to the old ProfileIOData > > code. If they're the same, then one transformation being correct implies the > > other is as well). > > > > I'm open to other ways to do this, but I don't see one, unless I inject a > > temporary callback into URLRequestContextBuilder to set up the proxy service, > > given the URLRequestContext being built, or subclass it in this file (Since it > > already has a virtual method for that). > > Ok, I pulled on my adult overhauls and sat down and verified the transformation > (with one question on behavior, in the new PS). But based on the above, I'm > curious as to what your long term plans are. What's going to happen to > ProxyServiceFactory? Are you leaving it alone, planning to remove > CreateProxyService(), or planning to delete the whole thing? It seems funny to > have pretty much the same code in two different places. Thanks for bringing this up! It looks like ProxyServiceFactory::CreateProxyService is no longer used (There's an iOS version, but it has a separate implementation), so I've gone ahead and removed it. I imagine we'll keep the other functions - we'll still be using a ProxyConfigTracker and ProxyConfigService in the browser process, we'll just be passing the config to the NetworkService. https://codereview.chromium.org/2978443002/diff/310001/chrome/browser/io_thre... File chrome/browser/io_thread.cc (right): https://codereview.chromium.org/2978443002/diff/310001/chrome/browser/io_thre... chrome/browser/io_thread.cc:801: LOG(ERROR) << "Cannot use V8 Proxy resolver in single process mode."; On 2017/07/18 18:26:54, Randy Smith (Not in Mondays) wrote: > So this looks to me like a potential change from the original. IIUC, > ProxyServiceFactory::CreateProxyService(), in this fallback case, would log the > error as above, would skip the ChromeMojoProxyResolverFactory as below, but > would also skip the dhcp_fetcher_factory assignment on ChromeOS. Is there some > reason why the kSingleProcess switch couldn't occur on ChromeOS? > > (I realize that we don't support kSingleProcess, but I don't think we want to > break it for ChromeOS unless there's a specific reason?) You're right that this is a change in behavior (I can't remember if it was intentional or not, though I think I did it because it seemed a bit tangential to whether we were using the V8 resolver or not). I'll go back the old behavior, since it is rather unrelated. I don't think that it really matters much, either way, as the DhcpFetcher still works, we just can't run PAC scripts. I bet we could use the V8 resolver in single process mode now if we really wanted to - the tracing resolver probably makes this a non-issue. But not worth the effort of looking into. :)
The CQ bit was checked by [email protected] to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by [email protected]
The CQ bit was checked by [email protected]
The patchset sent to the CQ was uploaded after l-g-t-m from [email protected] Link to the patchset: https://codereview.chromium.org/2978443002/#ps330001 (title: "Response to comments")
CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
CQ is committing da patch.
Bot data: {"patchset_id": 330001, "attempt_start_ts": 1500407542788700,
"parent_rev": "9a84ab56bfd1904c5bdd8da4eb3cfbbf75df0aad", "commit_rev":
"189ddf60b2f4034a2ab6efb16e22ea389b2b779f"}
Message was sent while issue was closed.
Description was changed from ========== Make ProfileIOData use URLRequestContextBuilder BUG=734199 ========== to ========== Make ProfileIOData use URLRequestContextBuilder BUG=734199 Review-Url: https://codereview.chromium.org/2978443002 Cr-Commit-Position: refs/heads/master@{#487590} Committed: https://chromium.googlesource.com/chromium/src/+/189ddf60b2f4034a2ab6efb16e22... ==========
Message was sent while issue was closed.
Committed patchset #12 (id:330001) as https://chromium.googlesource.com/chromium/src/+/189ddf60b2f4034a2ab6efb16e22...
Message was sent while issue was closed.
On 2017/07/18 20:34:53, commit-bot: I haz the power wrote: > Committed patchset #12 (id:330001) as > https://chromium.googlesource.com/chromium/src/+/189ddf60b2f4034a2ab6efb16e22... Gah - shouldn't have landed this, given branch was so close. Reverting. I'll merge the revert if needed.
Message was sent while issue was closed.
A revert of this CL (patchset #12 id:330001) has been created in https://codereview.chromium.org/2986623002/ by [email protected]. The reason for reverting is: Wasn't thinking when I landed this just before branch.. |
