Removal of old loading path (non network service)

[John Abd-El-Malek]

Hello Chromium embedders,

I wanted to give you a heads-up that the old loading path (e.g. ResourceDispatcherHostDelegate, ResourceThrottle, using net:: objects directly like URLFetcher, ProtocolHandler, NetworkDelegate, URLRequestInterceptor is currently unsupported on Win/Mac/Linux as of r635158. Soon, depending on our other launches (*), we will remove support in content/ for the old path. This will unblock a lot of simplification in content/ and chrome/.

If you're on Win/Mac/Linux/ChromeOS, then trunk already has the NetworkService feature enabled. If you're explicitly disabling it, or if you're on another platform and haven't converted yet, then this is a heads-up to convert real soon.

Thanks

*ChromeOS and Android are entering stable trials ChromeCast and Android WebView are getting close.

[Roger]

Thanks for the heads up. This is very helpful for me. Is there any issue to watch the progress. And is any timeline for the plan?

Roger

NW.js creator

--
You received this message because you are subscribed to the Google Groups "Chromium Embedders" group.
To unsubscribe from this group and stop receiving emails from it, send an email to embedder-dev...@chromium.org.
To post to this group, send email to embedd...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/CALhVsw0RQiJUx%3DZmyye7rpstLgh4cN9JS2j4a%3D%2BvdEBx%3D_MhvQ%40mail.gmail.com.

[John Abd-El-Malek]

On Thu, Mar 14, 2019 at 3:01 PM Roger <wen...@gmail.com> wrote:

Thanks for the heads up. This is very helpful for me. Is there any issue to watch the progress.

It's a bit hard to give specific guidelines, as each feature that has to be converted will vary depending on how it hooks today.

There are some guidelines for patterns we used here. You can also see design docs for different features linked here.

 

And is any timeline for the plan?

This will ultimately depend on how the launch for the rest of the platforms go. It could be as early as the beginning of July.

[Deepak Mohan]

Hi,

I am in the process of migrating legacy apis in Electron to enable network service. I was able to find the migration plan for 

* net::URLFetcher https://bugs.chromium.org/p/chromium/issues/detail?id=773295

* NetworkDelegate https://bugs.chromium.org/p/chromium/issues/detail?id=721414

* URLRequestContext https://bugs.chromium.org/p/chromium/issues/detail?id=825242

but unable to find the migration path for protocol handlers, at the moment I am extracting the URLRequestContext from the NetworkContext and resetting the URLRequestJobFactory with our custom handlers. I see that some custom request jobs in Chrome (ex: URLRequestExtensionJob) still use the legacy code path, whats the plan for this type of migration ?

Thanks,

Deepak 

[Marshall Greenblatt]

To answer your question I think we need to know the NetworkService equivalent of URLRequestContextBuilder::SetProtocolHandler. For example, this code that currently exists for extensions:

job_factory->SetProtocolHandler(

     extensions::kExtensionScheme,

     extensions::CreateExtensionProtocolHandler(is_incognito,

                                                extension_info_map_.get()));

 

Thanks,

Deepak 

--
You received this message because you are subscribed to the Google Groups "Chromium Embedders" group.
To unsubscribe from this group and stop receiving emails from it, send an email to embedder-dev...@chromium.org.
To post to this group, send email to embedd...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/47e7ef40-5f9c-4c74-ad34-e6509bdfe8ff%40chromium.org.

[Ken Rockot]

On Wed, Mar 20, 2019 at 2:07 PM Marshall Greenblatt <magree...@gmail.com> wrote:

On Tue, Mar 19, 2019 at 11:34 AM Deepak Mohan <hop2...@gmail.com> wrote:

Hi,

I am in the process of migrating legacy apis in Electron to enable network service. I was able to find the migration plan for 

* net::URLFetcher https://bugs.chromium.org/p/chromium/issues/detail?id=773295

* NetworkDelegate https://bugs.chromium.org/p/chromium/issues/detail?id=721414

* URLRequestContext https://bugs.chromium.org/p/chromium/issues/detail?id=825242

but unable to find the migration path for protocol handlers, at the moment I am extracting the URLRequestContext from the NetworkContext and resetting the URLRequestJobFactory with our custom handlers. I see that some custom request jobs in Chrome (ex: URLRequestExtensionJob) still use the legacy code path, whats the plan for this type of migration ?

To answer your question I think we need to know the NetworkService equivalent of URLRequestContextBuilder::SetProtocolHandler. For example, this code that currently exists for extensions:

job_factory->SetProtocolHandler(

     extensions::kExtensionScheme,

     extensions::CreateExtensionProtocolHandler(is_incognito,

                                                extension_info_map_.get()));

The browser passes a URLLoaderFactoryBundle to each render frame, which the frame can then use to get various URLLoaderFactory interfaces depending on what kind of resource it wants to fetch. Some of the bundled interfaces route to the Network Service, and some just route to browser-side implementations. For example, chrome-extensions:// URLs go to this implementation to fetch extensions resources.

Content embedders have an opportunity to register factories in every bundle that gets shipped off to a renderer. See Chrome's here (for general resource requests) and here (for navigation requests). This is e.g. where the chrome-extensions factories are registered.

 

 

Thanks,

Deepak 

--
You received this message because you are subscribed to the Google Groups "Chromium Embedders" group.
To unsubscribe from this group and stop receiving emails from it, send an email to embedder-dev...@chromium.org.
To post to this group, send email to embedd...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/47e7ef40-5f9c-4c74-ad34-e6509bdfe8ff%40chromium.org.

--

You received this message because you are subscribed to the Google Groups "network-service-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to network-service...@chromium.org.
To post to this group, send email to network-s...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/network-service-dev/CAFW9UJ-Z9Z4XRAHrLO%3DJM0nyAC%3D3AzSgsScmMgVnQ2iVR0vTJw%40mail.gmail.com.

[Deepak Mohan]

Thanks for the pointers! Its clear on how to register custom handlers and handle them. Follow up question, how does one go about intercepting existing URLLoaderFactory ? In pre network service world URLRequestJobManager had the builtin factories and we had option to chain custom URLRequestJobFactory to act as interceptors something like https://github.com/electron/electron/blob/master/atom/browser/net/url_request_context_getter.cc#L309-L324 .

I see embedders can provide interceptors in ContentBrowserClient::WillCreateURLLoaderRequestInterceptors , but unlike the legacy interceptors they are not scheme filtered but rather generic and embedders can apply their filters to respond with the necessary URLLoaders, is this understanding correct ? @Marshall pointed OfflinePageURLLoaderRequestInterceptor which uses this mechanism.

To unsubscribe from this group and stop receiving emails from it, send an email to network-service-dev+unsub...@chromium.org.

[John Abd-El-Malek]

On Wed, Mar 20, 2019 at 3:18 PM Deepak Mohan <hop2...@gmail.com> wrote:

Thanks for the pointers! Its clear on how to register custom handlers and handle them. Follow up question, how does one go about intercepting existing URLLoaderFactory ? In pre network service world URLRequestJobManager had the builtin factories and we had option to chain custom URLRequestJobFactory to act as interceptors something like https://github.com/electron/electron/blob/master/atom/browser/net/url_request_context_getter.cc#L309-L324 .

I see embedders can provide interceptors in ContentBrowserClient::WillCreateURLLoaderRequestInterceptors , but unlike the legacy interceptors they are not scheme filtered but rather generic and embedders can apply their filters to respond with the necessary URLLoaders, is this understanding correct ?

URLLoaderRequestInterceptor is very specific to navigations, and only when the embedder wants to take over some navigations and produce the response data for it. I suspect most embedders won't need to use this functionality.

For intercepting general requests (e.g. navigations, subresources, downloads) the recommended approach is to override content::ContentBrowserClient::WillCreateURLLoaderFactory. That also allows you to return different data. There are plenty of examples of this in the codebase now, see extensions::WebRequestProxyingURLLoaderFactory, signin::ProxyingURLLoaderFactory, android_webview::AwProxyingURLLoaderFactory.

To unsubscribe from this group and stop receiving emails from it, send an email to network-service...@chromium.org.

To post to this group, send email to network-s...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/network-service-dev/CAFW9UJ-Z9Z4XRAHrLO%3DJM0nyAC%3D3AzSgsScmMgVnQ2iVR0vTJw%40mail.gmail.com.

--

You received this message because you are subscribed to the Google Groups "Chromium Embedders" group.
To unsubscribe from this group and stop receiving emails from it, send an email to embedder-dev...@chromium.org.
To post to this group, send email to embedd...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/embedder-dev/e95f4ef9-a291-4292-8883-dd3c052b6ead%40chromium.org.

[John Abd-El-Malek]

Update: all of the platforms except Android WebView have launched to stable. So we will now start deleting code in src/chrome and src/components (that aren't used by src/android_webview). Android WebView will start stable trials next week, so by mid-late June if things go well we will then remove the old path in src/content and src/android_webview and any remaining src/components that are used by webview.