Freeze when hovering over "remove" or "delete rule"

[MiniGod]

Version

0.15.13

Operating System

Linux

Distribution Method

AppImage (Linux)

Describe the issue

If I hover over the "Delete rule" button, gitbutler freezes. I initially thought it was the dialog window that froze, but apparently, it happens on hover. I do have time to click it before it freezes. If I click it the dialog shows, then frozen. In the video below I'm just hovering. I'm unable to remove the rule.

Also happens when hovering over "Remove" in the "Remove project" popup. In the video below, you see the hover states. After hovering over "remove" in that popup, gitbutler freezes. I'm unable to remove the project.

Nothing is output to stdout/stderr when this happens. Also happened with 0.15.12. I don't know about earlier versions (updated from 0.12 or something to 0.15.12).

https://github.com/user-attachments/assets/8d3c2140-5d0c-4ef4-b429-691867e00ce4

https://github.com/user-attachments/assets/efa9316d-0001-4aa6-af37-5f10d2ff7f54

How to reproduce (Optional)

No response

Expected behavior (Optional)

No response

Relevant log output (Optional)

[Byron]

Thanks a lot for reporting!

This issue looks like it's easy to reproduce, but on MacOS at least that's not happening. Thus it's probably related to something with the browser engine that tauri ends up using.

As nobody in the team is working on Linux, it's unlikely to be get a fix anytime soon, but you might be able to see something when opening the developer tools.

If you find more contextual information, it might be enough to guide a copilot task towards a possible solution to try out.

[slarse]

I encountered this bug as well today and spent some time diagnosing it. I'm pretty sure the problem lies somewhere in the bundled libraries in the AppImage, specifically something related to libwebkit2gtk.

Here's what I've found:

Where it freezes

I've tried the released AppImages for 0.16.9, 0.17.6 and 0.18.0. I've tried both running the AppImage directly, and unpacking with ./<AppImage> --appimage-extract and then executed with the AppRun file.

All of these approaches freeze as described above. When shutting down after a freeze, I get this error:

** (WebKitWebProcess:110916): ERROR **: 22:48:11.491: WebProcess didn't exit as expected after the UI process connection was closed

Important: I ran into https://github.com/tauri-apps/tauri/issues/8929 and needed to build the AppImage with NO_STRIP=true.

Where it DOES NOT freeze

• Running the dev build locally (i.e. pnpm dev:desktop). This just runs fine.
• Building the AppImage locally and executing that. This also runs fine.

To diagnose the issue I started comparing my AppImage with the released AppImage. I noted that the usr/lib directories were rather different, both in which .so files are there and in the .so files that match (in terms of size). This is in part due to running without NO_STRIP=true, but I also noted that you use libwebkit2gtk-4.1-0=2.44.0-2 in your builds (that's pretty old, a year and a half or so), whereas I built locally with libwebkit2gtk-4.1-0=2.50.0-1.

I went as far as to clear out libwebkit2gtk and everything it depends on from the released AppImage, and just copy over the corresponding stuff from my own AppImage, and that also ran fine. Without the freeze.

For the curious, I did something like this

# released AppImage unpacked into gb-released-squashfs
# my local AppImage unpacked into gb-local-squashfs

# clear out libwebkit
cd gb-released-squashfs/usr/lib
ldd libwebkit2gtk-4.1.so.0 | grep -oP '\S*(?= =>)' | xargs rm
rm libwebkit2gtk-4.1.so.0

# copy in "good" libwebkit
cd ../../../gb-local-squashfs/usr/lib
ldd libwebkit2gtk-4.1.so.0 | grep -oP '\S*(?= =>)' | xargs -I_ cp _ ../../../gb-released-squashfs/usr/lib/
cp -r webkit2gtk-4.1/ ../../../gb-released-squashfs/usr/lib

Some more digging necessary

I'm kind of out of time now and haven't had the time to make a build with the particular version of libwebkit2gtk you are currently using, but I will try that tomorrow.

To summarize, the problem is likely either with the version of libwebkit2gtk just being too out of date, or that the binary stripping messes something up. I'm more inclined to believe it's just the old version that's the spanner in the wheel here, but I'll try to confirm that tomorrow.

[Byron]

Thanks so much for all this digging, and for sharing your results so well organised!

Now I realised that we do pin dependencies, a fact that I wasn't aware of.

https://github.com/gitbutlerapp/gitbutler/blob/1c4791f2d3513d9f49e61f9206cf85557bbd152f/.github/workflows/publish.yaml#L186-L192

And I will try to create a release with unpinned dependencies soon. TBC.

[Byron]

The current Nightly was built without the version pinning. We don't really have links there, so here is the version :D.

[slarse]

The new nightly unfortunately reintroduces https://github.com/gitbutlerapp/gitbutler/issues/5282. I believe that's the reason the version was pinned to begin with. I do not get that issue with build 0.5.1698.

I can experiment a little bit with different versions of WebkitGTK over the weekend. My hunch is that we need to go a little bit more bleeding edge than the stock Ubuntu repositories allow.

[Byron]

Thanks, let me undo that Nightly 😅, and thanks a lot for testing this out further.

[slarse]

I was struck down by a mighty cold and had to stow the laptop away for a few days :s

Anyhow, I've now concluded that it's not entirely the AppImage itself that is at fault. On two laptops, both with the same basic setup (Wayland under Arch, more on that a couple of paragraphs down), 0.17.6 freezes on both while 0.18.0 only freezes on one of them while working fine on the other. I triple checked that it's the exact same AppImage running on both. This at the very least proves that there is something external to the AppImage that contributes to the freezing.

Running with strace keeps showing activity when you e.g. move the cursor over the app, press keys, etc, so the app itself (even the UI) hasn't crashed. The UI just stops updating. On a scale of 1-10, I've got about a -3 knowledge level of WebkitGTK, so I really have no idea of how to further troubleshoot this.

Now that we're a couple of paragraphs down, I think it's important to note that the particular combination of parameters I've been digging into (Wayland on Arch) is rather uninteresting. It's pretty niche, and building from source is more the Arch way and also seems to be a stable workaround from my testing. For Arch in particular, we should just ensure that the AUR package(s) are well maintained instead of trying to get this AppImage working. Or, potentially, provide a "bleeding edge" AppImage in addition to the others.

But I think the place for the AppImage is more the enterprisey and mainstream distros, especially Debian. There, it's not feasible to go too bleeding edge as that'll cause incompatibilities with system libraries very quickly (most notably with glibc). I'll repurpose some spare hardware for at least one Debian-based system (probably Bookworm). From the Tauri devs' investigation, Debian Bookworm/Ubuntu 22 or later is the lower end for supporting the current version of WebkitGTK (API version 6 with GTK4), tow which Tauri is eventually moving. REHL situation seems rather hopeless. So I'll start there and work my way up. If we can get everything running smoothly on Debian Bookworm, that should unlock most of the Debian ecosystem, which is a much bigger win than getting it to run on Arch.

[Byron]

Glad to see you are back and… It seems like you will be maintaining the Linux distribution soon :). It can only get better from here, that's for sure. Thanks for everything!