Updating webkit2gtk

[pavel-demin]

Since this is a new module, would it be possible to update webkit2gtk to version 4.1 and replace the deprecated webkit_web_view_run_javascript with webkit_web_view_evaluate_javascript?

[SteffenL]

It's a good idea but it's something that must be solved in the core webview library.

I can see that we have a compile-time check near the usage of webkit_javascript_result_get_js_value so we can probably do the same thing here.

Do you mind filing the issue over at webview/webview?

[pavel-demin]

Thank you for your answer. I have just filled a new issue (webview/webview#1019).

If I am not mistaken, there is also a line of code in this repository that needs to be changed:

#cgo linux openbsd freebsd netbsd pkg-config: gtk+-3.0 webkit2gtk-4.0

I had to replace webkit2gtk-4.0 with webkit2gtk-4.1 to make it work with webkit2gtk 4.1.

[SteffenL]

I didn't immediately think of that. It makes things more complicated than I first imagined because the 4.1 API appears to only be available for the most recent Linux distros such as Ubuntu 22.04. Ubuntu 20.04 doesn't have the webkit2gtk-4.1. I imagine that hardcoding webkit2gtk-4.1 would exclude a whole bunch of users.

Do you have any ideas for how we could solve this?

A few (possibly bad) ideas come to my mind:

1. Stop hardcoding webkit2gtk-* but then we would force users to set the CGO_CXXFLAGS and CGO_LDFLAGS environment variables. It would break the normal Go workflow but it should be reliable at least.
2. Decide at runtime which version of WebKit2GTK to use and import it dynamically. How to find the headers without also linking the library?
3. Somehow provide two separate Go modules or packages where one uses webkit2gtk-4.1 and the other uses webkit2gtk-4.0. It would be nice if we could avoid duplicating more code.

I don't normally work with Go so it's hard for me to imagine the appropriate way to solve this.

[SteffenL]

In the core library I observed that using webkit_web_view_evaluate_javascript on Ubuntu 22.04 is possible even when linking webkit2gtk-4.0. Conditionally compiling this function or the other one will definitely get rid of the compile-time warning.

However, webkit_web_view_evaluate_javascript is available since WebKit2GTK 2.40 and Ubuntu 20.04 has WebKit2GTK 2.38. We cannot solve this with only a compile-time check because that would exclude too many users. We must dynamically import it when it's available.

Therefore we would have to also dynamically import the deprecated webkit_web_view_run_javascript to get rid of the warning.

If we can't find a simple solution to allow users of the Go binding to choose between webkit2gtk-4.0 and webkit2gtk-4.1 then my suggestion is that we only sort out the warning and compatibility issue in the core library and keep hardcoding webkit2gtk-4.0 in the Go binding.

[pavel-demin]

Thank you for the analysis of possible solutions.

If maintaining compatibility with older distributions is required, then it is probably best to wait a few more years before making these updates to this repository.

I initially thought that since this is a new module, then it would be OK to make a few more breaking changes. Otherwise, I do not insist on these changes.

[SteffenL]

webkit2gtk-4.1 is the same as webkit2gtk-4.0 except that 4.1 uses libsoup3 while 4.0 uses libsoup2. They can't co-exist in the same program so hardcoding one or the other in a library will cause problems for those who integrate libraries.

It does make some sense to move to webkit2gtk-4.1 but I wouldn't want to cut off users on slightly older Linux distros.

I've submitted a PR that attempts to address some of the problems in the core library:

• webview/webview#1022

This will use the webkit_web_view_evaluate_javascript when available or fall back to webkit_web_view_run_javascript without emitting a warning.

We could potentially solve the whole problem within the core library by dynamically importing all of the symbols from WebKit2GTK API 4.1 or 4.0, but Go would still be fighting us because of this line:

#cgo linux openbsd freebsd netbsd pkg-config: gtk+-3.0 webkit2gtk-4.0

And this would just cause compilation errors:

#cgo linux openbsd freebsd netbsd pkg-config: gtk+-3.0

If only we could tell cgo to pass the output of pkg-config --cflags webkit2gtk-4.0 to the compiler without also passing the output of pkg-config --libs webkit2gtk-4.0.

[powellnorma]

We could potentially solve the whole problem within the core library by dynamically importing all of the symbols from WebKit2GTK API 4.1 or 4.0

I too think that would be the best solution, since the produced binaries would be able to run on both older and newer distros.

Decide at runtime which version of WebKit2GTK to use and import it dynamically. How to find the headers without also linking the library?

Some Ideas..

1. Just add the result of pkg-config --cflags webkit2gtk-4.0 by hand. In case different distros use different paths, we could just add all of them
2. Tell the user to set PKG_CONFIG during build to a wrapper script we provide (as part of this repo). That wrapper script would handle webkit2gtk-4.0 in a specialized way

What do you think?

[titlestad]

Why would you change the argument count and make so much misory for developers utilizing this deprecated function? Couldn't you just make a wrapper instead of demanding that all other programmers must spend time and misory on updating heaps of code? Soon us programmers will spend 25% of our time updating code because of deprecation issues generated by lazy developers.