Bug 110141

Created attachment 189065 [details] Patch

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

Created attachment 205787 [details] Patch

(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.

Created attachment 205788 [details] Patch

(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.

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?

(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.

Created attachment 205789 [details] Patch

(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.

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.

(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?

(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.

(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.

> 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.

(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.

(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?

(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?

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

(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.

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’

> 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 :)

(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.

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.

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

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.

(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.

(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.

(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.

GTK now builds with network process enabled by default.

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.

(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.

(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.

(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.

(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.

(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.)

(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.

> > 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.

EFL builds with enabled network process long time ago.