fix(linux): reuse WebContext to prevent WebKitNetworkProcess leak

[KushalMeghani1644]

This PR fixes the issue where WebKitNetworkProcess instances are left running after closing Tauri windows on Linux.

When a webview is destroyed on Linux, the WebContext is removed from the context store if no other webviews reference it. When a new window is created later, a new WebContext is allocated, which spawns a new WebKitNetworkProcess. WebKit does not terminate these network processes when the context is dropped, leading to process accumulation.

Solution applied in this PR:

Keep the WebContext alive on Linux/BSD platforms even when all referencing webviews are closed. This allows the context to be reused by future webviews, ensuring only a single WebKitNetworkProcess is spawned during the application's lifetime.

Resolves

Issue: #14626

[github-actions]

Package Changes Through c5a327a

There are 3 changes which include tauri-utils with patch, tauri-build with patch, tauri-cli with patch

Planned Package Versions

The following package releases are the planned based on the context of changes in this pull request.

package	current	next
tauri-utils	2.8.1	2.8.2
tauri-bundler	2.7.5	2.7.6
tauri-runtime	2.9.2	2.9.3
tauri-runtime-wry	2.9.3	2.9.4
tauri-codegen	2.5.2	2.5.3
tauri-macros	2.5.2	2.5.3
tauri-plugin	2.5.2	2.5.3
tauri-build	2.5.3	2.5.4
tauri	2.9.5	2.9.6
@tauri-apps/cli	2.9.6	2.9.7
tauri-cli	2.9.6	2.9.7

Add another change file through the GitHub UI by following this link.

---

Read about change files or the docs at github.com/jbolda/covector

[FabianLars]

WebKit does not terminate these network processes when the context is dropped, leading to process accumulation.

I feel like fixing this would be the more appropriate but i wouldn't mind your approach that much if that's not possible, assuming that it's properly killed once the app actually exits.
I'm thinking about long-running tray apps here that only rarely open a window.

[FabianLars]

And perhaps it should also be investigated a bit upstream: tauri-apps/wry#590 though it may very well be possible that we just have to document that downstream (in this case tauri) has to handle this.

[KushalMeghani1644]

Hey @FabianLars

I feel like fixing this would be the more appropriate but i wouldn't mind your approach that much if that's not possible, assuming that it's properly killed once the app actually exits.
I'm thinking about long-running tray apps here that only rarely open a window.

for your concern of the tray applications I have added docs in the code that makes the behavior clear that the process will still terminate when the app exits since on Linux that's the expected behavior whenever an app closes!

And perhaps it should also be investigated a bit upstream: tauri-apps/wry#590 though it may very well be possible that we just have to document that downstream (in this case tauri) has to handle this.

Upon investigating the issue you mentioned I feel like the patch belongs to this repo only!

[FabianLars]

for your concern of the tray applications I have added docs in the code that makes the behavior clear that the process will still terminate when the app exits since on Linux that's the expected behavior whenever an app closes!

i was thinking that this would be kinda wasteful to keep processes open that aren't used. Like the rust process is like 5mb and we keep a 25mb process around for perhaps no reason? doesn't sound in line with tauri's philosophy to me.

[KushalMeghani1644]

i was thinking that this would be kinda wasteful to keep processes open that aren't used. Like the rust process is like 5mb and we keep a 25mb process around for perhaps no reason? doesn't sound in line with tauri's philosophy to me.

I understand your concerns @FabianLars but my idea or approach is that if we keep the process alive and the window closes there would be no further needs to restart that process again! which could speed up things! and as far as I know not many people would care about extra ~25Mb being used in their RAM as long as it's useful + gives a advantage! And if that doesn't sound good we can add a configurable option so the users can go to the tauri-conf.json and set true if they want the process alive or killed after the window is closed. What do you think?

[FabianLars]

and as far as I know not many people would care about extra ~25Mb being used in their RAM as long as it's useful + gives a advantage!

More efficient ram usage is one of the major reasons people switch to tauri and there's really not much of an advantage here as re-starting the network process is faster than re-starting the other processes so this should be done before you even notice it.

And if that doesn't sound good we can add a configurable option so the users can go to the tauri-conf.json and set true if they want the process alive or killed after the window is closed. What do you think?

For that we first have to fix the issue that prevents it from being killed :D I'd be okay with merging your change if it means we will investigate the actual issue and switch to the fix then. == We'd take your PR as a temporary workaround to get rid of the tens of zombie processes for now.

[KushalMeghani1644]

Thanks for the feedback @FabianLars I get it that keeping WebKitNetworkProcess alive is a minor memory overhead and that restarting it would be fast enough in most cases. So if you are fine with it... you can happily merge my PR as a temp work around and I will work on fixing this bug and adding the configurable option if you are fine with it :)

[FabianLars]

i'd very much appreciate it if you could look into the root issue here and fix it! Don't bother with a config though, that really isn't worth it, we don't keep any webview processes running on any platform so there's no reason to allow devs to do that for this single process :)

[KushalMeghani1644]

Thanks! @FabianLars I will investigate the root issue here and work on fixing this ASAP :D

[KushalMeghani1644]

Umm... hey! @FabianLars I did a bit of thorough investigation, and the results are quite interesting!
What I found?

WebKit itself is responsible, not Tauri :O

The root cause is in WebKit's architecture:

• WebKit spawns one WebKitNetworkProcess per WebsiteDataManager (which is wrapped by WebContext in webkit2gtk). This is by design, the NetworkProcess handles cookies, caching, and networking for all WebViews sharing that context.

• WebKit does NOT terminate the NetworkProcess when the WebContext is dropped this is intentional behavior in WebKit's multi-process model. The NetworkProcess is designed to persist because:
  - It holds persistent data (cookies, cache)
  - Restarting it is expensive
  - It's supposed to be shared across all WebViews
  - The bug is that each new WebContext spawns its own NetworkProcess, and when that WebContext is destroyed, the old NetworkProcess becomes orphaned but WebKit doesn't clean it up.

What to do?

The proper fix would be in WebKit upstream to either:

• Terminate NetworkProcess when all associated WebContexts are destroyed
• Share a single NetworkProcess across all WebContexts

So seems like my work-around works xD now my confusion is that if this is a WebKit issue on linux itself... I don't think there's much we can do, Maybe go and fix WebKit? xD IDK if you already knew this or not but yeah this is all I was able to find really.

[FabianLars]

This is so stupid but it's also such a webkit thing to do. Really makes no sense to me that it behaves that way with no way to opt-out

Thanks for the investigation nonetheless!

[KushalMeghani1644]

Glad it helped! @FabianLars, anyways... curious about what to do next for this issue?

[FabianLars]

hmm i guess nothing to do for you anymore. We need to test it ourselves now but i know that we're all insanely busy at work right now. Since i'm in the car with a hotspot for now maybe i can do it quickly now, can't actually work here anyway.

[FabianLars]

ah and we need a changefile similar to https://github.com/tauri-apps/tauri/pull/14620/changes#diff-4d219b4237dee6e7ef1d053a6c0ea396331048f5fcc8eb105d4b9813ee9e5e6b (but tauri-runtime-wry and patch)

[FabianLars]

Suggested change

	// On Linux/BSD, we keep the WebContext alive even when all windows are closed.
	// This ensures only one WebKitNetworkProcess is spawned for the lifetime of the app.
	// For tray-only or long-running apps, the process will still terminate when the application exits.
	// https://github.com/tauri-apps/tauri/issues/14626
	// Because WebKit does not close its network process even when no webviews are running, we need to ensure to re-use the existing process on Linux by keeping the WebContext alive for the lifetime of the app.
	// WebKit on macOS handles this itself.

formatting will be off but whatever

[FabianLars]

seems to work well in my quick test, thanks

[KushalMeghani1644]

seems to work well in my quick test, thanks

Thanks @FabianLars I have applied your suggestion with a clear formatting... if there are other changes please let-me know I will apply them ASAP :)

[FabianLars]

Thanks! I don't expect any changes but I'm away over the weekend (already am) so won't be able to merge until Monday earliest :)

[KushalMeghani1644]

Thanks! I don't expect any changes but I'm away over the weekend (already am) so won't be able to merge until Monday earliest :)

No problems! @FabianLars enjoy, take your time, and have fun!