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.

[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 ...

[davidjo]

My current experience with webkit2-gtk follows:

Having just got a new M4 mac (previous machine was intel) I am having to redo macports.

I have a "working" webkit2-gtk 2.40.5 for Gtk/Quartz.

My interest is in a working gnucash which uses webkit2-gtk for report rendering plus Javascript for plotting graphs.
Ive used a combo of patches from the current macports Portfile (2.28.3), macstrop git plus gnucashes jhbuild of webkit2-gtk (2.32.0) for the gnucash macos app.
This renders the Example reports for simple text and graphs in gnucash under macports as expected - whch is my only testing.
For me currently XQuartz (and macports Xorg) is unusable under M4/Sequoia as they both have a serious video glitch hence using macports quartz only (under intel just used XQuartz).

Some of the issues follow:
One was getting JIT to work as at 2.39.4 the MAC_OS_X symbol was changed to MACOS - this was the symbol a jhbuild patch used to activate the USE_PTHREAD_JIT_PERMISSIONS_API which is needed on arm to get Javascript to work and not SIGBUS due Apples "security bugs" (the original webkit2-gtk source uses PLATFORM(MAC)).
A number of OS(DARWIN) ifdefs needed switching to PLATFORM(COCOA) to disable them.
Also had to re-activate the MacTypes.h fixups from macstrop for os.major 24 (Sequoia).

[kencu (Ken)]

Kudos!

This is a fairly hard port to update!

[mascguy (Christopher Nielsen)]

Replying to davidjo:

I have a "working" webkit2-gtk 2.40.5 for Gtk/Quartz.

Ive used a combo of patches from the current macports Portfile (2.28.3), macstrop git plus gnucashes jhbuild of webkit2-gtk (2.32.0) for the gnucash macos app.

That's great news! Would you be interested in submitting a PR with your changes? Or alternatively, can you attach the patches here?

[davidjo]

tar of the Portfile plus patches under files

[davidjo]

Added a tar of the Portfile plus patches under the files directory.

Note that the current port name in the Portfile is webkit2-gtk-new1 rather than webkit2-gtk.

I also disabled document building because I got gir build errors for documentation.

[RJVB (René Bertin)]

Bah, the documentation must be available online, making building and installing it a waste of local resources!

[drkp (Dan Ports)]

I've been taking a look at what it would take to update this port to the latest version, and have a build of 2.52.3 that seems to be working so far!

This uses a combination of the approaches from @RJVB and @davidjo along with some new things.

Lots of things have changed between these versions, obviously. The largest one, as mentioned above, is that GLX was replaced by EGL, and we don't have EGL on MacOS, so webgl and accelerated compositing support are out. But we can add enough EGL header file stubs to get it to build, and then fall back to software rendering at runtime when it discovers no EGL displays are available.

The other major change, also mentioned above, is using libsoup 3 instead of 2 and hence requiring an update/rebuild of dependents. For the most part, unless the port is actually using libsoup2 itself, this should just be a matter of revbumping and possibly also changing the pkg-config dep to webkit-gtk-4.1 instead of -4.0. The more complicated ones are probably mostly fixable by updating the port; some of them are pretty outdated. (Actually, I'm not sure how many of the dependents even build at all now!)

A couple things are even simpler (for example, it's now using libgcrypt instead of CommonCryptoSPI).

I've tested this with the minibrowser, gnucash reports, and yelp, and it's looking promising. Have tried both +quartz and +x11, but so far only tested on arm64/Tahoe.

​https://github.com/drkp/macports-ports/tree/webkit2-gtk-2.52 if anyone wants to take a look. Will send a PR once I've tested it a bit more (though it may take a couple weeks before I can find time...).

[RJVB (René Bertin)]

• If you're only targetting newer Macs, isn't there an option to use Vulkan for rendering, possibly via an external build of ANGLE?

• At least until v2.44 it was possible to have parallel libsoup2 and libsoup3 based builds installed.

• EGL can be obtained through Mesa. This is also a CPU-based implementation of course, but it uses LLVM to speed things up as far as possible and it's quite usable. (I have the impression that Flatpak packages on Linux use it too).

• Webkit-GTk itself is pretty meh for the rest, at least if you want to use it for actual web browsing. I have a self-built v2.44.3 on my Linux rig and it crashes on a *lot* of sites. Of course it doesn't really help that there is not a single serious browser that's using it (basically only Epiphany, and that's comparable to an early Safari without support for browser extensions etc.)

For example, does the ​https://www.doctolib.fr site work in your build?

[drkp (Dan Ports)]

Sure, I guess the real question here is why we want this port at all. My specific use case is for rendering gnucash reports, and I suppose also for rendering HTML documentation in yelp. I think most of the dependents are similar use cases. It'd be nice if epiphany worked too (and I think it would with an update), but I can't imagine anyone wanting to use this for serious web browsing.

As a result, I think we should be happy with a solution that uses software rendering. If we really wanted to go the accelerated route, using ANGLE with the metal backend sounds like the most promising approach to me, but metal support isn't enabled in the angle port yet. EGL is also currently disabled in the mesa port. I'm not really inclined to spend much more time looking into that given the use cases I mentioned, but if someone else really feels motivated I won't stop them!

Replying to RJVB:

• At least until v2.44 it was possible to have parallel libsoup2 and libsoup3 based builds installed.

This is no longer true in the latest versions (hence the pkg-config version bump from -4.0 to -4.1).

For example, does the ​https://www.doctolib.fr site work in your build?

Seems fine in the minibrowser?

[RJVB (René Bertin)]

Replying to drkp:

Sure, I guess the real question here is why we want this port at all. My specific use case is for rendering gnucash reports, and I suppose also for rendering HTML documentation in yelp.

Yes, I think those would be the almost unavoidable reasons, but how recent a version does that really require?

It might also be a good idea to disable features (by default) that are less likely to be of use in such applications. Webkit has become very expensive to build, and it can be pretty demanding in terms of runtime resources too.

EGL is also currently disabled in the mesa port.

It's probably easier to enable EGL in Mesa than tweaking ANGLE. There are just some decisions to make about the required LLVM library. FWIW, Mesa's software EGL can also be used on remote X11 displays, so there's that advantage.

This is no longer true in the latest versions (hence the pkg-config version bump from -4.0 to -4.1).

The .pc files would be similarly versioned in parallel installations.

[drkp (Dan Ports)]

I'm not sure what you are proposing here exactly.

If you or someone else want to make EGL work with Mesa, or ANGLE with Metal, great. I can't say I have the time or inclination to work on it, and I don't think it's necessary for any of the major use cases of this port. And it can always be added later.

As for "how recent a version does that really require", I don’t see much value in deliberately targeting an already-stale intermediate release if the latest one builds and works with the ports that use it -- which seems to be the case here.

And yes, parallel API versions normally have separate .pc files. The problem is that libsoup2 support has been dropped from upstream webkit because libsoup2 has been EOL for a while; it's no longer possible to build it with this version.

[drkp (Dan Ports)]

To be more specific about dependents and the impact of libsoup3...

• 5 ports build fine with just a revbump or config patch to update the pkg-config file name:
  • gnucash
  • devhelp
  • glade
  • astroid
  • rednotebook
• 5 ports work with an update to a more recent version:
  • epiphany (to 42.5, the later versions use gtk4)
  • surf (to 2.1, the latest)
  • yelp (to 42.3, the latest)
  • zenity (to 3.44.5, the latest in the gnome 3 series)
  • gnome-online-accounts (to 3.48.3, though I admit I haven't tested it -- I don't have enough of the gnome stack installed)
• 9 ports were already broken before the update (at least on my system)
  • 4 of them can be fixed with an update and work fine with webkit-gtk 2.52
    • balsa
    • birdfont
    • liferea
    • geany-plugins
  • 3 of them are straight-up defunct and probably should be removed
    • empathy (discontinued in 2017)
    • midori (discontinued in 2024)
    • seed (webpage says it's unmaintained and ple should use GJS instead)
  • 2 others are broken due to clisp build failures
    • cl-webkit2
    • nyxt

The patches/updates for ones I've confirmed are fixable are already on my webkit2-gtk-2.52 branch. And we should probably decide what to do with the already-broken ones, which might include removing some of them.

[RJVB (René Bertin)]

Replying to drkp:

One reason not to target the "latest & greatest" version is that already v2.40.0 took quite an effort to get to build on older OS X versions, and when I finally got v2.44 (which I have on Linux) to install under 10.9.5, it turned out to KP my machine.

My argument against QtWebEngine has always been that it's complete overkill to link in an almost full-fledged browser just to display HTML documentation or emails; this is increasingly becoming valid for WebKit too.

I'm not sure what you are proposing here exactly.

One suggestion would be to split off a suitably recent version still using libsoup2 as port:webkit2-gtk-4.0 or something like that in line with the .pc file naming.

I'll admit that I've never tried WebKit's own software rendering, so I can't say anything about it, and I can't remember how straightforward it was to build WK against my Mesa+EGL port.

[drkp (Dan Ports)]

I'm not sure this discussion is productive. I am trying to get webkit2-gtk onto a more recent version for the sake of several ports I maintain or otherwise care about.

It may be that webkit is overkill for displaying documentation, but it's what these applications are using. We're not going to change that in this ticket. It may be that Mesa+EGL or Angle can give us better rendering performance. We can address that later if it matters.

Intentionally limiting everyone to an older webkit version for the sake of very old OS versions seems like a terrible idea to me. That just creates more work for the next update, while also preventing us from taking advantage of upstream bug fixes and security fixes. Given the current state of this port, that is exactly what I am trying to get away from. (And for the record, so far I have verified my portfile for 2.52 builds on every major release at least back to 10.15.)

It would be possible to provide an older version as a separate port, sure. But keeping one version of webkit working has proven enough of a challenge that I'm not thrilled about the idea of having another.

Is there an actual use case you're looking to support with a libsoup2 version? As I said above, _every_ working port we have that uses webkit2-gtk can be patched or updated to work with 2.52 and libsoup3, and I was even able to fix and update some of the currently-broken ones.

[drkp (Dan Ports)]

updated the list of dependents above (comment:36) -- apart from the two ports that are broken because they depend on clisp, everything is either now working or abandoned upstream and a candidate for removal

[drkp (Dan Ports)]

In a6441872523d8219fd242096736d48f76fd4a972/macports-ports (master):

webkit2-gtk: update to 2.52.4

Fixes: #65492

[Dave-Allured (Dave Allured)]

Dan, nice work! Do you have any plans to make those dependent rev bumps or updates, as you mentioned in (#comment:36) above?

[drkp (Dan Ports)]

Already done, see ​https://github.com/macports/macports-ports/pull/32758

[Dave-Allured (Dave Allured)]

Already done ...

Oops, how did I miss that? Thanks again!!