[bug] WebkitNetworkProcess not close when a window closed on Linux

[ctaoist]

Describe the bug

When we create a window, WebkitNetworkProcess and WebkitWebProcess will be created. If the window was closed, WebkitWebProcess would be closed, but WebkitNetworkProcess still was remained.

Reproduction

1. run multiwindow example: cargo run --example multiwindow --features window-create and create many windows
2. close those windows, and would find there are many WebkitNetworkProcess remained.

Expected behavior

WebkitNetworkProcess and WebkitWebProcess both would be closed when close a window.

Platform and versions

Environment
  › OS: Ubuntu 20.04 X64
  › Node.js: 16.15.0
  › npm: 8.10.0
  › pnpm: Not installed!
  › yarn: 1.22.18
  › rustup: 1.24.3
  › rustc: 1.60.0
  › cargo: 1.60.0
  › Rust toolchain: stable-x86_64-unknown-linux-gnu

Stack trace

No response

Additional context

No response

[keiya01]

I think this issue related to https://github.com/tauri-apps/wry/issues/536.

[keiya01]

I checked process by using top command. I think WebkitWebProcess and WebkitNetworkProcess are not closed on linux and macOS, but these processes are stoped. Therefore each process's memory are remained. I tried to remove WKWebsiteDataStore by using removeDataOfTypes on macOS, but memory usage was not reduced :(

[wusyong]

@keiya01 thank you for our hard research! If there's really no any other way. We'll probably add this in official site explaining that these processes won't be killed during the lifetime of application.

[keiya01]

Yeah, there is no way to kill network process. I will investigate or we can also propose to webkit about these feature.

[keiya01]

I thought over again about this issue. I think this issue is not problem. Because a networking process is shared between some web content processes and this process works to store some data like network caching, cookie, and so on. If the wkwebview can remove those data, a webview process need to fetch data again even when user opens new window that display same content. Also I found that a network process memory is not increased much even if we open a lot of window. So even if we can't remove networking process, I think this is not huge problem. Or rather, I think the wkwebview reuse caching data better than re-fetching removed data.

FYI: I think this image is helpful for understanding a networking process. This image is referred from Introduction to WebKit

[ctaoist]

Thanks to @keiya01 , I believe that there is no way to shutdown the network process.

But, is it possible to reuse the network process instead of creating a new one when tauri create a new window?

[keiya01]

Oh i see. Maybe we can use WKProcessPool. I will try to test WKProcessPool can share network process. And If we can do it, we need to consider interface about the way to optin WKProcessPool because sharing process may occur security issue like reading cookie from another webview unintentionally.

[ctaoist]

Oh i see. Maybe we can use [WKProcessPool]

After reading the intro of the WKProcessPool I feel like this is a excellent solution.

Thanks a lot for the test.

[keiya01]

I tried to use WKProcessPool, but it did not affect to networking process memory...

[keiya01]

I tried to use WKProcessPool in the following code. It looks like it reduced memory usage but it is not corroborated...

https://github.com/tauri-apps/wry/compare/feat/use-process-pool?expand=1

[probablykasper]

I can confirm this happens on macOS as well

[FabianLars]

Can someone on macos try the latest (stable) tauri version again? 1.2 included a change to explicitly drop the web context when a window closes, and at least on Linux this now seems to terminate the network process too. On that note, it seems to work the same on Wry's multi_window example (which doesn't explicitly use the WebContext) even though there wasn't a related commit as far as i can see.

Imo we should still look into using a shared webcontext across all windows since that seems to be how it's supposed to be, but that's not wry's responsiblity i think since there are use cases where you don't want to share it like private sessions.

[wusyong]

@FabianLars Wry's example can drop it successfully. But when I tested multiwindow with latest tauri commit, the first three windows couldn't drop it for some reasons. Other windows they create can still drop it successfully though.

[probablykasper]

It's still happening consistently on Tauri 1.2.3 on macOS