feat(linux): allow disabling WebViewUriLoader via feature

[dgerhardt]

A new feature flag linux-request-queue has been introduced, which is enabled by default to keep the previous behavior.

The WebViewUriLoader is a workaround for an unknown bug but disabling it can be useful because

• it introduces a deadlock situation, and
• the bug might no longer exist in newer WebKitGTK versions.

Refs tauri-apps/tauri#12589
Refs #359

[github-actions]

Package Changes Through a262a4b

There are 1 changes which include wry with minor

Planned Package Versions

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

package	current	next
wry	0.51.2	0.52.0

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

---

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

[dgerhardt]

@chippers @wusyong Could you have a look at this PR? It is related to a workaround introduced with #359, which you submitted/reviewed.

[lucasfernog]

shouldn't this be done via a configuration in the webview attributes instead of a feature flag?

[lucasfernog]

it's also a pretty feature creepy config anyway

[dgerhardt]

@lucasfernog I've used a feature under the assumption that the marked code is a preparation for a complete removal in the future when the underlying Webkit2GTK issue has been fixed.

If you think that a webview attribute would be more appropriate in this case, I'm happy to adjust the PR.

[dgerhardt]

I had a look at implementing this using PlatformSpecificWebViewAttributes. I might be missing something, but I don't see a way to override the attribute defaults for webviews on the application side. It wouldn't make much sense to pass the setting to every single webview on creation since you would either globally enable or disable the workaround.

[lucasfernog]

can you check if the deadlock is still happening? i don't see much value in this kind of config, it's a bit too much IMO

[dgerhardt]

I ran the reproduction against the dev branch and the deadlock now is no longer consistently reproducible, but it still occurs in rare cases. I get around one case of a deadlock when running the reproduction 20 times.

i don't see much value in this kind of config, it's a bit too much IMO

Since the issue the workaround is supposed to fix isn't well documented (there is no reproduction code or linked GH issue), it is hard to tell if it still exists. So instead of removing it directly, I used a feature flag for opting out to allow more testing before a removal.

But I've done a lot of testing with the workaround removed and opening a lot of webviews in parallel and could not reproduce the bug (tested on Ubuntu 24.04 using libwebkit2gtk-4.1-0@2.48.3-0ubuntu0.24.04.1). The workaround has been around since mid 2021, so it is not unlikely the issue was fixed upstream in the meantime. Do you think it would be better to just completely remove the workaround? I would open a new PR in this case.

[dgerhardt]

@lucasfernog I've opened #1605, which removes the workaround instead of introducing a new feature flag.

[dgerhardt]

Closing this since #1605 has been merged.