[linux] Add support for WebKitGTK 2.36+

[stffabi]

Is your feature request related to a problem? Please describe.

WebKitGTK 2.36+ brings support for several new features when processing requests from the frontend, like response status codes, headers, http methods.

This would be especially interesting to bring the AssetsHandler at almost the same feature level like the other platforms and allows it to be used for a new plugin concept.

Describe the solution you'd like

Add support for WebKitGTK 2.36+ and implement available features on the AssetsHandler.

Describe alternatives you've considered

No response

Additional context

It should be discussed in which form we want to add the new minimal dependency.

• Just require WebKITGTK 2.36+ for any build.
• Make it configurable to also allow building with an older version at the cost of loosing the new features.

2.36.0 has been released on March 21st, 2022 so it might be that not all distributions have already updated to it. On the other hand it seems like SecurityUpdates are only provided for the last major minor release. But still distributions might track their own branch with backports.

[leaanthony]

I'm wondering if there's a cgo/build flag way of doing this then let the developer decide or there might be a runtime check we can do

[stffabi]

We could check during runtime on what version we run, so we could e.g. check we are on 2.36+ and if not fail with a message dialog or silently loose features.

The main question I think is, if we want to hard require 2.36+ or silently allow an older version and loose some features during runtime. Loosing features might be okey for some users, for others not, depending if they use those features or not. So that might be a choice a developer needs to make in some way.

[mholt]

Generally I'm in the camp of "upgrade your stuff" (it's an unpopular opinion to some sysadmins but I do it anyway, with my own projects) so I'd personally be fine with "Just require WebKITGTK 2.36+ for any build" especially because it will be simpler and more reliable.

Personally, I don't want to ship an app that pretends like it works on some older system but is actually broken.

[leaanthony]

Yeah I generally agree, but this will only be good if that version of WebKit is available on the target system. And by "available" I mean they can install it via the default package manager. If this is not true then the app won't work anyway. If we provide a capabilities API then the app developer can choose to use the 2.36 features if available or carry on as normal if not. We sort-of had this situation with webview2 runtime but at least there was a single way we could get the end user to install the dependency if unavailable. That's now almost certainly moot.

[stffabi]

WebKit2GTK 2.36 is out since march 2022, there's already another minor release out since then 2.30. So I personally I would also be fine with requiring now at least 2.36.

Maybe we could specify what minimum version one does wan't to compile against and add a runtime check for the minimum requirement. That should be pretty easily doable with go build-tags.

[stffabi]

I still have some code laying around from early 2.36 tests of the AssetHandler. Will try to polish that a little bit und push that so we could build upon that.

[leaanthony]

If it's available for most distros then I have no issues with that at all!

[stffabi]

Cleanup is almost finished. I've put everything behind go buildtags. So we could either build against pre 2.36 or 2.36+

Maybe I will try to complete it with adding a runtime check and a messagedialog if the target machine doesn't meet the required minimal version.

What would be interesting in that case to define a default set of build tags in wails.json, like mentioned in #1937