#1054150 surf: no longer display web pages after webkitgtk upgrades

Package:
surf
Source:
surf
Description:
Simple web browser by suckless community
Submitter:
Dominique Martinet
Date:
2025-04-20 15:51:02 UTC
Severity:
normal
#1054150#5
Date:
2023-10-18 08:06:16 UTC
From:
To:
Dear Maintainer,

After upgrading my system to the latest security updates surf no longer displays anything.
The pages actually load, hovering on links shows the cursor changing and links can be clicked, but the page is blank

I've tested both in VMs on debian bullseye (this bug report) and debian stable on real hardware (2.1+git20221016-4), both exhibit the same issue.

For bullseye, this package upgrade reliably triggers the issue, and installing old packages back makes surf work again:
Unpacking libwebkit2gtk-4.0-37:amd64 (2.42.1-1~deb11u1) over (2.40.5-1~deb11u1) ...
Unpacking libjavascriptcoregtk-4.0-18:amd64 (2.42.1-1~deb11u1) over (2.40.5-1~deb11u1) ...

Thanks you
#1054150#10
Date:
2023-10-20 07:02:07 UTC
From:
To:
This seems to be the same problem as reported for the 'tauri' web
browser here:
https://github.com/tauri-apps/tauri/issues/7927

They've reported a workaround of setting this variable, which I've
confirmed to work with surf as well:
WEBKIT_DISABLE_COMPOSITING_MODE=1

So something in the GPU acceleration code broke for small users of
webkitgtk...

I don't have much time to look further right now, but I'll keep looking
as time permits...

Thanks,
#1054150#15
Date:
2023-10-20 09:12:52 UTC
From:
To:
I checked and every other WebKitGTK browser that I tested in bullseye
works fine (epiphany, luakit, midori, giara, and WebKitGTK's own
MiniBrowser), so I suspect that there's something odd that Surf is
doing.

Until this is investigated I would just run it with
WEBKIT_DISABLE_COMPOSITING_MODE=1. Surf could also be patched
downstream in Debian to force this, it also needs to force the x11
backend because its Wayland support is broken (see #1012739).

Berto
#1054150#20
Date:
2023-10-20 14:19:55 UTC
From:
To:
I had a look at this, the problem is caused by Surf's AppArmor
configuration.

I can make it run on my computer with something like this added to
/etc/apparmor.d/usr.bin.surf, but your mileage may vary:

  /sys/devices/virtual/dmi/id/chassis_type r,
  /etc/glvnd/egl_vendor.d/ r,
  /etc/glvnd/egl_vendor.d/** r,
  /usr/share/glvnd/egl_vendor.d/ r,
  /usr/share/glvnd/egl_vendor.d/** r,
  /usr/share/libdrm/* r,

I think that Surf's AppArmor profile is just too restrictive for a
program that has so many dependencies.

Berto
#1054150#25
Date:
2023-10-23 00:24:32 UTC
From:
To:
Alberto Garcia wrote on Fri, Oct 20, 2023 at 04:19:55PM +0200:

d'oh ! I need to remember debian now ships this on by default...

Thanks, I can confirm this works for me as well on various systems
(bullseye VM and bookworm with intel GPU)

(I'm especially annoyed because I saw these in strace output, but the
previous version of webkit also used to try to look at chassis_type and
egl_vendor.d directories so I dismissed that too fast... It's possible
previous versions of webkit were also disabling compositing mode due to
the apparmor rules, but the new one fails to disable it properly when it
didn't find what it wanted there? If so I guess one could argue that's a
bug on its own)

Right, I guess it's a tight line between trying to sandbox a web browser
and allowing all sort of things a web browser might need to do...
I'll leave follow-ups to Reiner (surf's maintainer), and definitely
remember about apparmor next time.

Thank you again for looking Alberto !
#1054150#32
Date:
2025-04-20 15:48:44 UTC
From:
To:
I am unable to duplicate this issue with Debian Testing using GNOME.

I tested by running GDK_BACKEND=x11 surf https://debian.org/

There have been an enormous amount of changes in webkit2gtk since
October 2023 and this issue may have been fixed.

If you are still affected by this issue in Debian 12 or Unstable or
Testing, please report a new bug.

Thank you,
Jeremy Bícha