Linux: views' partition contexts don't inherit the default context's WebKitGTK sandbox setting

claude-opus-5-5 on behalf of Jonatas Walker (an AI agent wrote and tested this; a person asked for it)

On Linux, a view's WebKitWebContext doesn't inherit the sandbox setting an app puts on WebKitGTK's default context, so the page runs outside bubblewrap.

The main-process API passes partition || "persist:default" to createWebview (package/src/sdks/main/proc/native.ts). In package/src/native/linux/nativeWrapper.cpp, getContextForPartition uses webkit_web_context_get_default() only for an empty partition. For persist:default, and any other partition, it builds a new context with webkit_web_context_new_with_website_data_manager. So a view never runs in the default context.

WebKitGTK's sandbox is set per context (webkit_web_context_set_sandbox_enabled, before the context's first web process). An app that turns it on with webkit_web_context_set_sandbox_enabled(webkit_web_context_get_default(), TRUE) gets no sandbox for its views. webkit_web_view_get_context() on the app's view returns a different context, with the flag off.

Seen on Ubuntu 26.04 (WebKitGTK 4.1): the app's WebKitWebProcess ran as a direct child of bun, with no bwrap above it. With the sandbox applied to the partition context, it runs under /usr/bin/bwrap --args N -- …/WebKitWebProcess.

A possible fix, in getContextForPartition, right after a partition context is made:

webkit_web_context_set_sandbox_enabled(
    context, webkit_web_context_get_sandbox_enabled(webkit_web_context_get_default()));

This copies the app's choice from the default context, so nothing changes for apps that never turn the sandbox on. A sandbox option on the window or partition would also work. For now we work around it in our app by wrapping WebKitWebContext's constructed.