Bug 110141 – [WK2] Make Efl build and run with ENABLE_NETWORK_PROCESS

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit2

[Balazs Kelemen]

Just need some ifdefs to fix the build (and the other patches blocking bug 108832).

[Balazs Kelemen]

Created attachment 189065 [details]
Patch

[Kwang Yul Seo]

Changed the subject to "[WK2] Make Gtk and Efl build and run with ENABLE_NETWORK_PROCESS".

[Kwang Yul Seo]

Created attachment 205787 [details]
Patch

[Kwang Yul Seo]

(In reply to comment #3)
I made four changes to the original patch:
1. Add PLATFORM(MAC) guard around CookieStorageShim in WebProcess.cpp

2. Make Gtk build and run with ENABLE_NETWORK_PROCESS
- Implement executablePathOfNetworkProcess() in ProcessExecutablePathGtk.cpp
- Handle NetworkProcess type in ProcessLauncher::launchProcess().
- Implement internalError(const WebCore::KURL&) in WebErrorsGtk.cpp.

3. Don't use ResourceRequest::nsURLRequest in NetworkResourceLoader.cpp.

4. Add USE(PROTECTION_SPACE_AUTH_CALLBACK) guard in NetworkResourceLoader.messages.in.

[Kwang Yul Seo]

Created attachment 205788 [details]
Patch

[Kwang Yul Seo]

(In reply to comment #5)
Build fix for ENABLE(NETWORK_PROCESS)=0. 

Also changed m_launchOptions.processType check in ProcessLauncher::launchProcess to use switch for code readability.

[Sergio Villar Senin]

Comment on attachment 205788 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=205788&action=review

Overall looks good except the changes in mac code

> Source/WebKit2/ChangeLog:12
> +        Add guard agains ENABLE(CUSTOM_PROTOCOLS).

typo "agains"

> Source/WebKit2/ChangeLog:15
> +        Don't use newRequest.nsURLRequesta as it is Mac port specific.

nsURLRequest

> Source/WebKit2/ChangeLog:20
> +        * Shared/WebResourceBuffer.h: Changed forward declaration of ShareableResource to actual

actually

> Source/WebKit2/NetworkProcess/NetworkResourceLoader.cpp:217
> +    m_suggestedRequestForWillSendRequest.updateFromDelegatePreservingOldHTTPBody(newRequest);

This does not seem correct for the Mac port.

> Source/WebKit2/Shared/WebResourceBuffer.h:-34
> -

Why?

[Kwang Yul Seo]

(In reply to comment #7)
Thanks for the review. I will fix typos and check how nsURLRequest(DoNotUpdateHTTPBody) works.

> This does not seem correct for the Mac port.
> 
> > Source/WebKit2/Shared/WebResourceBuffer.h:-34
> > -
> 
> Why?

There is an explanation in the ChangeLog. 

Changed forward declaration of ShareableResource to actual include because GCC requires a definition of the type for passing it in a PassOwnPtr.

[Kwang Yul Seo]

Created attachment 205789 [details]
Patch

[Kwang Yul Seo]

(In reply to comment #9)
> Created an attachment (id=205789) [details]
> Patch

I made a few changes to the previous patch:
1. Fix typos in the ChangeLog.
2. Add ENABLE(NETWORK_PROCESS) guard to NetworkResourceLoader.messages.in.
3. Add PLATFORM(MAC) guard in NetworkResourceLoader::continueWillSendRequest()

+#if PLATFORM(MAC)
m_suggestedRequestForWillSendRequest.updateFromDelegatePreservingOldHTTPBody(newRequest.nsURLRequest(DoNotUpdateHTTPBody));
+#else
+    m_suggestedRequestForWillSendRequest.updateFromDelegatePreservingOldHTTPBody(newRequest);
+#endif

I don't fully understand what nsURLRequest does here. Tell me if this is wrong. I will investigate it more in the meantime.

[Brady Eidson]

Comment on attachment 205789 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=205789&action=review

Not quite ready.  Enough questions.

> Source/WebKit2/NetworkProcess/NetworkResourceLoader.cpp:221
> +#if PLATFORM(MAC)
>      m_suggestedRequestForWillSendRequest.updateFromDelegatePreservingOldHTTPBody(newRequest.nsURLRequest(DoNotUpdateHTTPBody));
> +#else
> +    m_suggestedRequestForWillSendRequest.updateFromDelegatePreservingOldHTTPBody(newRequest);
> +#endif

I wish we could find a sensible way to avoid this.

> Source/WebKit2/Shared/WebResourceBuffer.h:-34
> +#include "ShareableResource.h"
>  #include <WebCore/ResourceBuffer.h>
>  
>  namespace WebKit {
>  
> -class ShareableResource;
> -

The ChangeLog indicates this undesirable change is because of GCC requirements.

Why does GCC have this deficiency?

Was the deficiency in GCC fixed in a later version?

There's been a vocal and public push to move the compiler dependencies in the project forward, and WebKit2 has traditionally been the flagship of this effort.  Is it truly unavoidable to have to make this type of change?

> Source/WebKit2/UIProcess/Network/NetworkProcessProxy.cpp:32
>  #include "AuthenticationChallengeProxy.h"
> -#include "CustomProtocolManagerProxyMessages.h"
>  #include "DownloadProxyMessages.h"

I think the fact that CustomProtocolManagerProxyMessages.h is in the ENABLE(NETWORK_PROCESS) block means that...

> Source/WebKit2/UIProcess/Network/NetworkProcessProxy.cpp:45
> +#if ENABLE(CUSTOM_PROTOCOLS)
> +#include "CustomProtocolManagerProxyMessages.h"
> +#endif

...this block should also be in the ENABLE(NETWORK_PROCESS) block.

In other words, there's no such thing as enabling custom protocol support without enabling network process support, and the code should reflect this.

> Source/WebKit2/WebProcess/Network/WebResourceLoader.cpp:111
> +#if USE(CFNETWORK)
>      responseCopy.setCertificateChain(certificateInfo.certificateChain());
> +#endif

I understand this is (currently) necessary because of code in WebCore, which is too bad.

We should push "PlatformCertificateInfo" to WebCore and make the ResourceRequest/Response primitives work in terms of that platform agnostic object instead of CF-specific types.

> Source/WebKit2/WebProcess/WebCoreSupport/efl/WebErrorsEfl.cpp:78
> +WebCore::ResourceError internalError(const WebCore::KURL& url)
> +{
> +    return ResourceError(WebError::webKitErrorDomain(), kWKErrorInternal, url.string(), ASCIILiteral("Internal error"));
> +}

It's too bad that this code...

> Source/WebKit2/WebProcess/WebCoreSupport/gtk/WebErrorsGtk.cpp:80
> +WebCore::ResourceError internalError(const WebCore::KURL& url)
> +{
> +    return ResourceError(WebError::webKitErrorDomain(), kWKErrorInternal, url.string(), ASCIILiteral("Internal error"));
> +}

...and this code are direct copies of each other.

But I suppose EFL and GTK could theoretically diverge here, as they are already divergent from Mac...

which leads me to this question - Is there any reason why these are divergent from Mac?  Seems like the section of errors in WebErrorsMac.mm labelled "// Otherwise, fallback to our own errors."  *could* be 100% cross platform.

[Kwang Yul Seo]

(In reply to comment #11)
> The ChangeLog indicates this undesirable change is because of GCC requirements.
> 
> Why does GCC have this deficiency?
> 
> Was the deficiency in GCC fixed in a later version?
> 
> There's been a vocal and public push to move the compiler dependencies in the project forward, and WebKit2 has traditionally been the flagship of this effort.  Is it truly unavoidable to have to make this type of change?

This change was in the original patch written by Balazs Kelemen. I double-checked and found that this is not needed at least in GCC 4.7. I will revert the change because we already limit the supported compilers to GCC >= 4.7 and Clang >= 3.0 (Bug 109932).

Balazs, do you remember the version of GCC you had this problem?

[Kwang Yul Seo]

(In reply to comment #11)
> But I suppose EFL and GTK could theoretically diverge here, as they are already divergent from Mac...
> 
> which leads me to this question - Is there any reason why these are divergent from Mac?  Seems like the section of errors in WebErrorsMac.mm labelled "// Otherwise, fallback to our own errors."  *could* be 100% cross platform.

The implementation of all errors functions in WebErrorsGtk.cpp and WebErrorsEfl.cpp is identical. Each function delegates to the corresponding function in WebCore.

In WebCore (ErrorsEfl.h/cpp, ErrorsGtk.h/cpp), two ports differ in how they create an error message. Gtk port localizes the error message with _ macro while Efl port uses the error message (in English) as is without localization.

So I should have localized the "Internal error" message in Gtk port. I will fix it.

[Kwang Yul Seo]

(In reply to comment #11)
> We should push "PlatformCertificateInfo" to WebCore and make the ResourceRequest/Response primitives work in terms of that platform agnostic object instead of CF-specific types.

Okay. I will file a separate bug to refactor this.

[Balazs Kelemen]

> This change was in the original patch written by Balazs Kelemen. I double-checked and found that this is not needed at least in GCC 4.7. I will revert the change because we already limit the supported compilers to GCC >= 4.7 and Clang >= 3.0 (Bug 109932).
> 
> Balazs, do you remember the version of GCC you had this problem?

No :) Anyway it is good if we can avoid my workaround.

[Kwang Yul Seo]

(In reply to comment #11)
> > Source/WebKit2/UIProcess/Network/NetworkProcessProxy.cpp:32
> >  #include "AuthenticationChallengeProxy.h"
> > -#include "CustomProtocolManagerProxyMessages.h"
> >  #include "DownloadProxyMessages.h"
> 
> I think the fact that CustomProtocolManagerProxyMessages.h is in the ENABLE(NETWORK_PROCESS) block means that...
> > Source/WebKit2/UIProcess/Network/NetworkProcessProxy.cpp:45
> > +#if ENABLE(CUSTOM_PROTOCOLS)
> > +#include "CustomProtocolManagerProxyMessages.h"
> > +#endif
> 
> ...this block should also be in the ENABLE(NETWORK_PROCESS) block.

This block is in the ENABLE(NETWORK_PROCESS) block because the entire file is in the ENABLE(NETWORK_PROCESS) block.

[Kwang Yul Seo]

(In reply to comment #11)
> > Source/WebKit2/NetworkProcess/NetworkResourceLoader.cpp:221
> > +#if PLATFORM(MAC)
> >      m_suggestedRequestForWillSendRequest.updateFromDelegatePreservingOldHTTPBody(newRequest.nsURLRequest(DoNotUpdateHTTPBody));
> > +#else
> > +    m_suggestedRequestForWillSendRequest.updateFromDelegatePreservingOldHTTPBody(newRequest);
> > +#endif
> 
> I wish we could find a sensible way to avoid this.

I am not sure how to avoid this as only the Mac port has a platform specific URL request object (m_nsRequest) and doUpdatePlatformRequest, doUpdateResourceRequest, doUpdatePlatformHTTPBody and doUpdateResourceHTTPBody do nothing in soup. 

Any suggestion?

[Kwang Yul Seo]

(In reply to comment #11)
> > Source/WebKit2/WebProcess/Network/WebResourceLoader.cpp:111
> > +#if USE(CFNETWORK)
> >      responseCopy.setCertificateChain(certificateInfo.certificateChain());
> > +#endif
> 
> I understand this is (currently) necessary because of code in WebCore, which is too bad.
> 
> We should push "PlatformCertificateInfo" to WebCore and make the ResourceRequest/Response primitives work in terms of that platform agnostic object instead of CF-specific types.

BTW, why do we pass PlatformCertificateInfo as a separate argument in WebResourceLoader::DidReceiveResponseWithCertificateInfo message? Can we simply change the argument coders of ResourceResponse to include certificate chain instead of manually setting it here?

[Alexey Proskuryakov]

PlatformCertificateInfo objects are large, so we don't send them automatically with every ResourceResponse serialization.

[Kwang Yul Seo]

(In reply to comment #19)
> PlatformCertificateInfo objects are large, so we don't send them automatically with every ResourceResponse serialization.

Okay. I filed a bug to push PlatformCertificateInfo to WebCore. See Bug 118520.

[Csaba Osztrogonác]

Comment on attachment 205789 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=205789&action=review

>> Source/WebKit2/Shared/WebResourceBuffer.h:-34
>> -
> 
> The ChangeLog indicates this undesirable change is because of GCC requirements.
> 
> Why does GCC have this deficiency?
> 
> Was the deficiency in GCC fixed in a later version?
> 
> There's been a vocal and public push to move the compiler dependencies in the project forward, and WebKit2 has traditionally been the flagship of this effort.  Is it truly unavoidable to have to make this type of change?

I don't know why does GCC have this problem, I'm not a GCC developer. :)
But I can confirm that GCC 4.6.3 needs this change. It is the default
compiler on the latest Ubuntu LTS (12.04) And I don't think if we should
expect all user install custom GCC because of only this simple problem.

Here is the build log without this change:
/home/ossy/WebKitNix/Source/WebKit2/Shared/WebResourceBuffer.cpp:34:1: error: prototype for ‘WebKit::WebResourceBuffer::WebResourceBuffer(WTF::PassRefPtr<WebKit::ShareableResource>)’ does not match any in class ‘WebKit::WebResourceBuffer’
/home/ossy/WebKitNix/Source/WebKit2/Shared/WebResourceBuffer.h:36:7: error: candidates are: WebKit::WebResourceBuffer::WebResourceBuffer(const WebKit::WebResourceBuffer&)
/home/ossy/WebKitNix/Source/WebKit2/Shared/WebResourceBuffer.h:47:5: error:                 WebKit::WebResourceBuffer::WebResourceBuffer(WTF::PassRefPtr<ShareableResource>)
/home/ossy/WebKitNix/Source/WebKit2/Shared/WebResourceBuffer.cpp: In member function ‘virtual const char* WebKit::WebResourceBuffer::data() const’:
/home/ossy/WebKitNix/Source/WebKit2/Shared/WebResourceBuffer.cpp:46:52: error: invalid use of incomplete type ‘struct ShareableResource’
/home/ossy/WebKitNix/Source/WebKit2/Shared/WebResourceBuffer.h:32:7: error: forward declaration of ‘struct ShareableResource’
/home/ossy/WebKitNix/Source/WebKit2/Shared/WebResourceBuffer.cpp: In member function ‘virtual unsigned int WebKit::WebResourceBuffer::size() const’:
/home/ossy/WebKitNix/Source/WebKit2/Shared/WebResourceBuffer.cpp:51:22: error: invalid use of incomplete type ‘struct ShareableResource’
/home/ossy/WebKitNix/Source/WebKit2/Shared/WebResourceBuffer.h:32:7: error: forward declaration of ‘struct ShareableResource’
/home/ossy/WebKitNix/Source/WebKit2/Shared/WebResourceBuffer.cpp: In member function ‘virtual bool WebKit::WebResourceBuffer::isEmpty() const’:
/home/ossy/WebKitNix/Source/WebKit2/Shared/WebResourceBuffer.cpp:56:38: error: invalid use of incomplete type ‘struct ShareableResource’
/home/ossy/WebKitNix/Source/WebKit2/Shared/WebResourceBuffer.h:32:7: error: forward declaration of ‘struct ShareableResource’
In file included from /home/ossy/WebKitNix/Source/WTF/wtf/RefPtr.h:29:0,
                 from /home/ossy/WebKitNix/Source/WTF/wtf/VectorTraits.h:26,
                 from /home/ossy/WebKitNix/Source/WTF/wtf/Vector.h:31,
                 from /home/ossy/WebKitNix/Source/WebCore/platform/SharedBuffer.h:33,
                 from /home/ossy/WebKitNix/Source/WebCore/loader/ResourceBuffer.h:29,
                 from /home/ossy/WebKitNix/WebKitBuild/Release/DerivedSources/WebKit2/include/WebCore/ResourceBuffer.h:1,
                 from /home/ossy/WebKitNix/Source/WebKit2/Shared/WebResourceBuffer.h:30,
                 from /home/ossy/WebKitNix/Source/WebKit2/Shared/WebResourceBuffer.cpp:27:
/home/ossy/WebKitNix/Source/WTF/wtf/PassRefPtr.h: In function ‘void WTF::derefIfNotNull(T*) [with T = ShareableResource]’:
/home/ossy/WebKitNix/Source/WTF/wtf/PassRefPtr.h:67:39:   instantiated from ‘WTF::PassRefPtr<T>::~PassRefPtr() [with T = ShareableResource]’
/home/ossy/WebKitNix/Source/WebKit2/Shared/WebResourceBuffer.h:38:137:   instantiated from here
/home/ossy/WebKitNix/Source/WTF/wtf/PassRefPtr.h:52:13: error: invalid use of incomplete type ‘struct ShareableResource’
/home/ossy/WebKitNix/Source/WebKit2/Shared/WebResourceBuffer.h:32:7: error: forward declaration of ‘struct ShareableResource’

[Balazs Kelemen]

> I don't know why does GCC have this problem, I'm not a GCC developer. :)
> But I can confirm that GCC 4.6.3 needs this change. It is the default
> compiler on the latest Ubuntu LTS (12.04) And I don't think if we should
> expect all user install custom GCC because of only this simple problem.
> 

Users? People how want to touch WebKit are developers :) It's not a big deal updating gcc if the default on your distribution is old.

On the other hand it is not a big deal to add an extra include. Actually relying on where and how the compiler will instantiate template code is very error prone.

I wonder why don't we have a section in Platform.h or somewhere that intentionally fails with an #error if the compiler is too old. This way we could avoid having these debates :)

[Csaba Osztrogonác]

(In reply to comment #22)
> > I don't know why does GCC have this problem, I'm not a GCC developer. :)
> > But I can confirm that GCC 4.6.3 needs this change. It is the default
> > compiler on the latest Ubuntu LTS (12.04) And I don't think if we should
> > expect all user install custom GCC because of only this simple problem.
> > 
> 
> Users? People how want to touch WebKit are developers :) It's not a big deal updating gcc if the default on your distribution is old.

:) Of course, it's not a big deal for me or for an other developer. But it
can be problem if each developer run into this cryptic error message again
and again. It's not trivial to determine if you need newer GCC if you see
this error.

Otherwise In my opinion developing WebKit should be as smooth as possible,
so we shouldn't expect more and more dependencies day by day from all
developers. In this point I agree with Apple's philosophy that WebKit
build should work out-of-the box on the latest OSX relase. It should
be true on the most popular Linux distributions' latest LTS releases.
 
> On the other hand it is not a big deal to add an extra include. Actually relying on where and how the compiler will instantiate template code is very error prone.

Agree. That's why I can't understand why should we drop GCC 4.6 
support, if we can fix it easily with s/class Foo;/#include <Foo.h>/ .
I think, it's not so serious situation where we should force everyone
to update his/her compiler to GCC 4.7 or 4.8.

> I wonder why don't we have a section in Platform.h or somewhere that intentionally fails with an #error if the compiler is too old. This way we could avoid having these debates :)

I think because there isn't any consensus about which compiler is too old
or not. There are developers who want to use always the newest compilers
and force others to use it too, and there are developers who support older
platforms and they have to use what they have on these platforms. For example
there is still needs for GCC 4.4 support. Not 4.6, but 4.4, because "The
latest Red Hat Enterprise Linux ships with GCC 4.4.":
https://bugs.webkit.org/show_bug.cgi?id=119266#c13

On the other hand, it isn't the best place for this discussion, but
webkit-dev mailing list. The port maintainers should determine which
is the oldest compiler they want to support, not you and not me.

[Csaba Osztrogonác]

I think this bug tries to solve many different issues. In my 
opinion it would be better if we'd fix this bug step by step.

I'm going to split the latest patch and upload them soon
to bugs added to the depends on list.

[Csaba Osztrogonác]

Comment on attachment 205789 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=205789&action=review

>> Source/WebKit2/UIProcess/Network/NetworkProcessProxy.cpp:32
>>  #include "DownloadProxyMessages.h"
> 
> I think the fact that CustomProtocolManagerProxyMessages.h is in the ENABLE(NETWORK_PROCESS) block means that...

.

>> Source/WebKit2/UIProcess/Network/NetworkProcessProxy.cpp:45
>> +#endif
> 
> ...this block should also be in the ENABLE(NETWORK_PROCESS) block.
> 
> In other words, there's no such thing as enabling custom protocol support without enabling network process support, and the code should reflect this.

The problem is here that cmake ports don't generate CustomProtocolManagerProxyMessages.h at all, because they don't need it. 
Originally r141174 added this include into the following file:
- http://trac.webkit.org/changeset/141174/trunk/Source/WebKit2/UIProcess/WebProcessProxy.cpp
- http://trac.webkit.org/changeset/141174/trunk/Source/WebKit2/UIProcess/Network/NetworkProcessProxy.cpp

and then cmake http://trac.webkit.org/changeset/141203/trunk/Source/WebKit2/UIProcess/WebProcessProxy.cpp fixed
it partially, because nobody tried to do ENABLE_NETWORK_PROCESS=1 build that time.

There are 2 possible fix for it:
- including CustomProtocolManagerProxyMessages.h conditionally
- adding CustomProtocolManagerProxy.messages.in to the cmake build system to generate the useless CustomProtocolManagerProxyMessages.h

Let's continue the discussion about it in the new bug: https://bugs.webkit.org/show_bug.cgi?id=121417

[Csaba Osztrogonác]

Comment on attachment 205789 [details]
Patch

I finished splitting it to smaller patches and added 
new bug reports with patches to the depends on list.

[Brian Holt]

(In reply to comment #23)
> (In reply to comment #22)
> > > I don't know why does GCC have this problem, I'm not a GCC developer. :)
> > > But I can confirm that GCC 4.6.3 needs this change. It is the default
> > > compiler on the latest Ubuntu LTS (12.04) And I don't think if we should
> > > expect all user install custom GCC because of only this simple problem.
> > > 
> > 
> > Users? People how want to touch WebKit are developers :) It's not a big deal updating gcc if the default on your distribution is old.

> Otherwise In my opinion developing WebKit should be as smooth as possible,
> so we shouldn't expect more and more dependencies day by day from all
> developers. In this point I agree with Apple's philosophy that WebKit
> build should work out-of-the box on the latest OSX relase. It should
> be true on the most popular Linux distributions' latest LTS releases.
...
> Agree. That's why I can't understand why should we drop GCC 4.6 
> support, if we can fix it easily with s/class Foo;/#include <Foo.h>/ .
> I think, it's not so serious situation where we should force everyone
> to update his/her compiler to GCC 4.7 or 4.8.

Actually, we have to move to 4.7.x anyway for C++11 support which means that 12.04 LTS is just not recent enough for WebKit developers if you want to use the out-of-the-bx GCC.

[Csaba Osztrogonác]

(In reply to comment #27)
...
> > Agree. That's why I can't understand why should we drop GCC 4.6 
> > support, if we can fix it easily with s/class Foo;/#include <Foo.h>/ .
> > I think, it's not so serious situation where we should force everyone
> > to update his/her compiler to GCC 4.7 or 4.8.

This bug isn't valid anymore, see https://bugs.webkit.org/show_bug.cgi?id=121436#c5 for details.
 
> Actually, we have to move to 4.7.x anyway for C++11 support which means that 12.04 LTS is just not recent enough for WebKit developers if you want to use the out-of-the-bx GCC.

Which c++11 features do you mean? 

It would be great to have an announcment on webkit-dev about dropping 
GCC 4.6 support, because many of us still use 12.04 LTS with GCC 4.6.
Now the EFL and the Nix port build fine with GCC 4.6 for me.

[Brian Holt]

(In reply to comment #28)
> 
> Which c++11 features do you mean? 
> 
> It would be great to have an announcment on webkit-dev about dropping 
> GCC 4.6 support, because many of us still use 12.04 LTS with GCC 4.6.
> Now the EFL and the Nix port build fine with GCC 4.6 for me.

Perhaps I spoke too soon, but I moved to 12.10 explicitly because of an C++11 failure I had building WebKit (approx 9 months ago) when the debate about moving to C++11 was happening.  Those issues with 4.6 must have been resolved in the mean time.

[Carlos Garcia Campos]

GTK now builds with network process enabled by default.

[Gyuyoung Kim]

When I run EFL MiniBrowser, I failed to find NetworkProcess even though EFL port has built NetworkProcess files. I guess EFL port just build the files. Any info about it ?

CC'ing Anderca.

[Csaba Osztrogonác]

(In reply to comment #31)
> When I run EFL MiniBrowser, I failed to find NetworkProcess even though EFL
> port has built NetworkProcess files. I guess EFL port just build the files.
> Any info about it ?
> 
> CC'ing Anderca.

NetworkProcess isn't used by default, it depends on the process model.
It is enabled if you use multiple secondary process model. (-S option 
of EFL MiniBrowser) If you are interested in it, there is a quite
simple bug related to enabled NetworkProces - bug137692.

GTK experimented to make using NetworkProcess by default, but as far
as I remember they had issues with tests, maybe they already solved them.
I'll check the git history to find these issues.

[Gyuyoung Kim]

(In reply to comment #32)
> (In reply to comment #31)
> > When I run EFL MiniBrowser, I failed to find NetworkProcess even though EFL
> > port has built NetworkProcess files. I guess EFL port just build the files.
> > Any info about it ?
> > 
> > CC'ing Anderca.
> 
> NetworkProcess isn't used by default, it depends on the process model.
> It is enabled if you use multiple secondary process model. (-S option 
> of EFL MiniBrowser) If you are interested in it, there is a quite
> simple bug related to enabled NetworkProces - bug137692.

Thank you Ossy ! I have forgotten about it. If patch owner isn't interested in the issue, I would like to take over it. Let me check it as well.

[Csaba Osztrogonác]

(In reply to comment #32)
> (In reply to comment #31)
> > When I run EFL MiniBrowser, I failed to find NetworkProcess even though EFL
> > port has built NetworkProcess files. I guess EFL port just build the files.
> > Any info about it ?
> > 
> > CC'ing Anderca.
> 
> NetworkProcess isn't used by default, it depends on the process model.
> It is enabled if you use multiple secondary process model. (-S option 
> of EFL MiniBrowser) If you are interested in it, there is a quite
> simple bug related to enabled NetworkProces - bug137692.
> 
> GTK experimented to make using NetworkProcess by default, but as far
> as I remember they had issues with tests, maybe they already solved them.
> I'll check the git history to find these issues.

See bug138428 for details.

[Carlos Garcia Campos]

(In reply to comment #32)
> (In reply to comment #31)
> > When I run EFL MiniBrowser, I failed to find NetworkProcess even though EFL
> > port has built NetworkProcess files. I guess EFL port just build the files.
> > Any info about it ?
> > 
> > CC'ing Anderca.
> 
> NetworkProcess isn't used by default, it depends on the process model.
> It is enabled if you use multiple secondary process model. (-S option 
> of EFL MiniBrowser) If you are interested in it, there is a quite
> simple bug related to enabled NetworkProces - bug137692.
> 
> GTK experimented to make using NetworkProcess by default, but as far
> as I remember they had issues with tests, maybe they already solved them.
> I'll check the git history to find these issues.

Yes, we had some issues with some tests that revealed actual bugs :-) Some other cases were tests that simply don't work with the network process and we just skipped them. But since then we are running the layout tests using the network process.

[Csaba Osztrogonác]

(In reply to comment #33)
> Thank you Ossy ! I have forgotten about it. If patch owner isn't interested
> in the issue, I would like to take over it. Let me check it as well.

Balázs isn't working on it long long time ago, feel free to pick 
it up. But it is a meta bug, so I suggest doing it in a new bug report.
(Build already works fine, maybe MiniBrowser and tests work too, but
they should be checked.)

[Gyuyoung Kim]

(In reply to comment #36)
> (In reply to comment #33)
> > Thank you Ossy ! I have forgotten about it. If patch owner isn't interested
> > in the issue, I would like to take over it. Let me check it as well.
> 
> Balázs isn't working on it long long time ago, feel free to pick 
> it up. But it is a meta bug, so I suggest doing it in a new bug report.
> (Build already works fine, maybe MiniBrowser and tests work too, but
> they should be checked.)

Ok, let me check about it when I have spare time.

[Balazs Kelemen]

> 
> Thank you Ossy ! I have forgotten about it. If patch owner isn't interested
> in the issue, I would like to take over it. Let me check it as well.

Gyuyoung, you are more than welcome to take it over.

[Csaba Osztrogonác]

EFL builds with enabled network process long time ago.