webkit2-gtk update?

[RJVB (René Bertin)]

Is there a reason why port:webkit2-gtk is considerably behind upstream (2.27.3 vs 2.36.4)?

[kencu (Ken)]

It's often quite hard to update, as darwin is not an officially supported or tested platform -- have at it! It usually takes a fair bit of hacking and patching to get it to build.

[kencu (Ken)]

there is another request to update here 64554

[RJVB (René Bertin)]

It takes a more (less?!) than fair bit of time to build too, and even small changes tend to trigger a full rebuild where ccache usually is of little to no assistance.

I see my own version (in my LinuxPorts) is currently at 2.28.2 and builds on Mac too, in case someone wants to merge that slightly less outdated version. Can't say it works very well when tested with Epiphany, though but my GTk3 install isn't exactly up-to-date either.

[kencu (Ken)]

MP has 2.28.2 also.

​https://ports.macports.org/port/webkit2-gtk/details/

don’t ask me why devel version is older :)

You are right, it is OK for simple stuff it seems, like the gtk help files, but crashes frequently with major, common, websites.

I came to the conclusion somehow the crashes were due to kernel message passing, but that is really speculative.

[kencu (Ken)]

well, you could ask me why devel is older, as I last updated the main port.

I guess I planned to update the devel port to 2.29.x but bogged down.

[RJVB (René Bertin)]

Replying to kencu:

MP has 2.28.2 also.

Doh, I guess I got confused with another port (not the devel one I mean).

Kernel message passing, in what context?

I too find that many websites crash, and also with the Linux build. That one uses mostly the same patches so one of the Darwin-specific ones could explain why the Linux build is slightly (but academically) more stable.

Funny thing is that the older WebKit code used by the rebooted Qt WebKit (not in MacPorts AFAIK) is a lot more stable; the front-end (browser) and glue (Qt vs. GTk) could thus have some impact here.

Oh well. As long as the framework is reliable as a renderer for HTML documentation and the like that's already a big gain over Chrome/WebEngine which is severely overkill for such tasks.

[RJVB (René Bertin)]

BTW, I was surprised that there is apparently no GTk4 port yet. Haven't at all looked at it (a sample app using it I pulled in via Flatpak was so fugly I immediately removed it ;) ) but one could hope that Quartz support would be better in that new version. Which could potentially make WK2-gtk more stable and more interesting.

[mascguy (Christopher Nielsen)]

Currently working on updating webkit2-gtk. The patches are the challenge, as they require very careful scrutiny to ensure they're correct.

I'm most of the way there, and will start by updating webkit2-gtk-devel. Then we'll reconcile webkit2-gtk, once we're sure everything's in good shape.

[RJVB (René Bertin)]

Replying to mascguy:

Currently working on updating webkit2-gtk. The patches are the challenge, as they require very careful scrutiny to ensure they're correct.

I would have said that stability is the challenge, but that probabably boils down to the same thing...

[catap (Kirill A. Korinsky)]

Christopher, any progress on it?

[mascguy (Christopher Nielsen)]

Replying to catap:

Christopher, any progress on it?

I haven't looked at this in the past few months, but the ongoing work is available in my personal repo:

​https://github.com/mascguy/macports-ports/tree/mascguy-webkit2-gtk-devel

I welcome collaboration, if you or anyone else is interested...

[catap (Kirill A. Korinsky)]

Thanks for sharing it.

I try to make upstream of Nyxt to suggest to use MacPorts to install it on macOS :) And the only blocker is too old webkit2

See: ​https://github.com/atlas-engineer/nyxt/pull/3119

[diogob003 (Diogo)]

WebKitGtk is huge, has different versions, WebKit1 vs WebKit2 and still have multiple API versions which works with different GTK versions.

WebKitGtk version	WebKit arch	pkgconfig / API	GTK version	macport's port
2.0.0 ~ 2.4.x	WebKit1	webkit-1.0	gtk2	webkit-gtk-2.0
	WebKit1	webkitgtk-3.0	gtk3	webkit-gtk3-2.0
	WebKit2	webkit-1.0	gtk2	webkit-gtk
	WebKit2	webkitgtk-3.0	gtk3	webkit-gtk3
2.5.1 ~ 2.3x.x	WebKit2	webkit2gtk-4.0	gtk3	webkit2-gtk
2.3x.x ~ 2.40.x	WebKit2	webkit2gtk-4.0	gtk3+libSoup2
	WebKit2	webkit2gtk-4.1	gtk3+libSoup3
	WebKit2	webkit2gtk-5.0	gtk4
2.40.x ~ 2.xx.x	WebKit2	webkit2gtk-4.0	gtk3+libSoup2
	WebKit2	webkit2gtk-4.1	gtk3+libSoup3
	WebKit2	webkitgtk-6.0	gtk4

Note: don't trust my numbers, I don't usually use WebKit, that's what I remember right off the bat. What matters is "pkgconfig / API" and "GTK version"

Ports "webkit-gtk3-2.0", "webkit-gtk-2.0" and "webkit-gtk3" are old, dead with no manteiners and no ports that depends on it.

"webkit-gtk" is almost dead with only two old ports that depends on it.

I think "webkit2-gtk" need to be updated and set "-DUSE_SOUP2=OFF" to generate API webkit2gtk-4.1. There is almost no difference between API "webkit2gtk-4.0" and "webkit2gtk-4.1" apart from "libSoup" version. So ports that depends on "webkit2-gtk" should still work when updated.

And perhaps someone might need to create a subPort with "-DUSE_GTK4=ON \ -DUSE_SOUP2=OFF" to generate "webkitgtk-6.0" that works with gtk4.

[RJVB (René Bertin)]

Replying to diogob003:

There is almost no difference between API "webkit2gtk-4.0" and "webkit2gtk-4.1" apart from "libSoup" version. So ports that depends on "webkit2-gtk" should still work when updated.

What about ports that link to libsoup directly, like midori? I just rebuilt that one with libsoup{,-2.4} both present, and the build system picked up libsoup-2.4 . Or port:epiphany . This might not be a problem if the library was written with the possibility in mind, provided that webkit2-gtk keeps its soup "in-house", but does it?

The crucial question here is probably whether the webkit2gtk-4.1 API also gives a "significantly" more modern/extensive HTML support.

[RJVB (René Bertin)]

Replying to mascguy:

I welcome collaboration, if you or anyone else is interested...

Will see if I can come up with something. I've compiled a few additional patches for the current 2.28.2 version, too (​https://github.com/RJVB/macstrop/tree/master/www/webkit2-gtk).

Re the note about BUILDING_GTK__: why not simply ensure that this gets defined in the appropriate header, for +x11 installs? Formally that should be done by port:gtk3 I suppose, but if webkit2-gtk is the only GTk port that needs this it could be done in the mentioned WebkitAvailability.h file?!

Side-bar: wouldn't it be great if we could have the native WebKit build in MacPorts also (supposing it's not OS/version-locked through ObjC)?

[RJVB (René Bertin)]

Replying to RJVB:

Will see if I can come up with something.

Initial impression is that 2.40.1 will build webkit2gtk-4.1 by default, but also that this will probably install cleanly alongside the current webkit2gtk-4.0 namespace of the current version of the port. The few WKG dependents in MP that I checked all require webkit2gtk-4.0 so this almost invites the creation of a webkit2-gtk-4.1 subport that just sets -DUSE_SOUP2=OFF while the main port sets it to -DUSE_SOUP2=ON!

[RJVB (René Bertin)]

​https://github.com/mascguy/macports-ports/pull/1

Updated the patches for pre-10.13 systems. Contrary to v2.28.2 I've had to disable the use of EGL because of a build failure; this may be because I have a patched Mesa install that includes (some form of) EGL support.

EDIT: looks more like I need to disable WEB_GL for now as somehow the build gets flagged as being for Linux and to use EGL even if CMake didn't find it.

EDIT 240312 : link to the PR.

[RJVB (René Bertin)]

As a general remark: I finally got the port to build on 10.9, only to have my Mac KP twice after having used it. Once while using it, the 2nd time was a night and sleep/wake cycle after having run Epiphany against WK2-gtk-devel 2.40.2 . Both times I had increased the use-of-shared-memory limits to avoid a GTk3 BadAccess error I reported on elsewhere, but needless to say I didn't keep trying and reverted to the tried-and-true WK2-gtk 2.28 main port.

And just now I see that you really need clang-17 to build C++20 code: ​https://discourse.llvm.org/t/rfc-clang-17-0-6-would-be-minimum-version-to-build-llvm-in-c-20/75345/8 and that using something as older as clang-12 (like I did) could cause all kinds of unexpected behaviour because of silent miscompiles.

The problem is that clang++-17 really seems to require a more recent libc++ runtime, one that provides std::verbose_abort (IIRC).

[kencu (Ken)]

I think we have the std::verbose_abort issue sorted out.

I haven't pushed the fix to clang-17 just yet, but I did push the clang-16 fix for that.

[RJVB (René Bertin)]

Hmm, I never noticed it with clang-16 to date (though I use that one as little as possible too). I would have expected that the fix was upgrading port:libcxx to 17.x but apparently you found an easier one that "just" requires to rebuild clang? :)

[RJVB (René Bertin)]

Replying to mascguy:

I now have a port:webkit2-gtk@2.40.1 and (more importantly?) port:webkit2-gtk-4.1@2.40.1 that build and work with GTk/X11 on Mac and Linux: ​https://github.com/RJVB/macstrop/tree/master/www/webkit2-gtk .

A bit overenthusiastically I thought I'd go and update this to a newer version, leading to port:webkit2-gtk-devel-4.1@2.44.3 that works on Linux and is actually the current stable WebKit version.

Naively I started to work on getting it to build on Mac, only to realise after hours of building that the GTk port has been EGL-only for a while (since webkit commit #ec3dd91419a8c035ddb2c79bbd85a93619bab1e9). According to git describe that is 2.39.7.2116 ... suggesting it's certainly not newer than 2.40.x ...

@mascguy : is there a reason you chose 2.40.1 or was that just the current stable release when you started working on it? I see 2.40.5 still has GLX support (Source/WebCore/platform/graphics/GLContext.h exists) but 2.41.1 not anymore (the file was moved to Source/WebCore/platform/graphics/egl/GLContext.h).

EDIT: their commit #ec3dd91419a8c035ddb2c79bbd85a93619bab1e9 was in March 16 2023, the 2.40.5 release on Aug. 1st 2023 . That kind of begs the question what's more important, 5 months of potential security upgrades and/or backports from the master branch, or 5 months of potential new features on the master branch ...