The 'surf' autopkgtests are failing in Debian and Ubuntu, it seems it started after the 2.41.4 -> 2.41.5 update. Testing with 2.41.91 on an ubuntu mantic GNOME/xorg (surf errors out on wayland) or xfce env confirms the problem, WEBKIT_DISABLE_COMPOSITING_MODE=1 workaround the issue here but WEBKIT_DISABLE_DMABUF_RENDERER=1 doesn't ``` $ LANG= LC_ALL=C surf http://www.ubuntu.com (surf:7089): dbind-WARNING **: 12:35:05.078: Couldn't connect to accessibility bus: Failed to connect to socket /run/user/1000/at-spi/bus_0: Permission denied ** (surf:7089): WARNING **: 12:35:05.126: Could not open /sys/class/dmi/id/chassis_type: Failed to open file ?/sys/class/dmi/id/chassis_type?: Permission denied ** (surf:7089): WARNING **: 12:35:05.126: Could not open /sys/firmware/acpi/pm_profile: Failed to open file ?/sys/firmware/acpi/pm_profile?: Permission denied (surf:7089): IBUS-WARNING **: 12:35:05.172: Unable to load /var/lib/dbus/machine-id: Failed to open file ?/var/lib/dbus/machine-id?: Permission denied (surf:7089): IBUS-WARNING **: 12:35:05.172: open /home/ubuntu/.config/ibus/bus failed: Permission denied Cannot get default EGL display: EGL_BAD_PARAMETER Cannot create EGL context: invalid display (last error: EGL_SUCCESS) ``` The EGL errors aren't there when using WEBKIT_DISABLE_COMPOSITING_MODE=1 Debian had failing tests also and fixed it with this change * debian/control-common.in: - Add dependency on libgles2. This is no longer detected automatically because it's loaded at runtime by libepoxy (see #1050777). but that isn't working on Ubuntu. Strace shows it's loading /lib/x86_64-linux-gnu/libGL.so.1 /lib/x86_64-linux-gnu/libEGL.so.1 and /lib/x86_64-linux-gnu/libGLX.so.0 but not libGLES
MiniBrowser displays the webpages correctly $ /usr/lib/x86_64-linux-gnu/webkit2gtk-4.1/MiniBrowser http://www.ubuntu.com libEGL warning: DRI2: failed to authenticate libEGL warning: pci id for fd 15: 1b36:0100, driver (null) (unsure if the warnings there are of any use; but strace shows that it does load libGLESv2.so.2 at the difference of surf)
(In reply to seb128 from comment #0) > Strace shows it's loading > /lib/x86_64-linux-gnu/libGL.so.1 /lib/x86_64-linux-gnu/libEGL.so.1 and > /lib/x86_64-linux-gnu/libGLX.so.0 but not libGLES Well that seems very relevant. Carlos Garcia says that WebKitGTK requires GLES nowadays. I wonder why it's not loaded.
And it's especially weird that MiniBrowser works fine. I wonder what could surf possibly be doing that could break this.
I tried reproducing this on Fedora 39 but surf works perfectly fine for me if I set GDK_BACKEND=x11. (Without that, it crashes immediately due to improper X11 assumptions.) It's very suspicious that it also works on Debian (now that the GLES dependency is installed) and only fails on Ubuntu. That's really weird. I have no clue what could be causing this.
As I mentioned in the Debian bug report surf takes whatever default display is available but only works properly on X11, so you can force GDK_BACKEND=x11 to avoid spurious issues.
Has anyone here a pointer on where is the logic deciding which GL stack to use or know if there is any debug environment that would give more information about why it's taking the current glpath?
It always uses GLES (and EGL). WebKitGTK does not support desktop GL (or GLX) anymore, so there's no longer any logic to decide between them. I would expect a failure like this only if GLES is not installed, but you've verified that it is. I don't know what to try next. At least the impact is fairly minor, unless you're a surf user on Ubuntu. I was expecting this rendering issue would affect all applications and all distros. It's really strange that other applications are fine and only surf is affected, and also really strange that Debian is fine and only Ubuntu is affected.
The web process only supports GLES2 now, so eglBindAPI uses EGL_OPENGL_ES_API unconditionally and contexts are created for an EGLConfig having EGL_OPENGL_ES2_BIT as EGL_RENDERABLE_TYPE. The UI process does support OpenGL and GLES2, it just uses whatever the app is using, but in the case of surf it doesn't matter because x11 doesn't use hardware acceleration in the UI process.
I though it might be a different in our Ubuntu webkitgtk build but installing the debs from Debian on the mantic VM still shows the same behaviour. Installing the mesa from Debian (rebuild on mantic but same source) also doesn't resolve the bug. OUr wpe and wpebackend-fdo are also on the exact same version...
Ok, I figured it out, it's a problem due to apparmor, I didn't know surf was including an apparmor profile the journal has audit: type=1400 audit(1694175887.447:1795): apparmor="DENIED" operation="open" class="file" profile="/usr/bin/surf" name="/etc/machine-id" pid=94729 comm="surf" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 audit: type=1400 audit(1694175892.387:1811): apparmor="DENIED" operation="open" class="file" profile="/usr/bin/surf" name="/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/app-org.gnome.Terminal.slice/vte-spawn-64263ce8-7b7e-4897-a75c-d2ae2c3de03e.scope/memory.current" pid=94729 comm="PressureMonitor" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000 audit: type=1400 audit(1694175887.383:1789): apparmor="DENIED" operation="open" class="file" profile="/usr/bin/surf" name="/usr/share/glvnd/egl_vendor.d/" pid=94729 comm="surf" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 audit: type=1400 audit(1694175887.383:1790): apparmor="DENIED" operation="open" class="file" profile="/usr/bin/surf" name="/sys/devices/virtual/dmi/id/chassis_type" pid=94729 comm="surf" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 audit: type=1400 audit(1694175887.383:1791): apparmor="DENIED" operation="open" class="file" profile="/usr/bin/surf" name="/sys/firmware/acpi/pm_profile" pid=94729 comm="surf" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 unsure what restriction is creating the issue exactly but once the profile is put in complain mode then the rendering works again I don't know if that's a sign that some fallback code in webkit in not working when the egl init is error out but from my perspective it can be closed, sorry for wasting your time there
ah, the profile is blocking access to /usr/share/glvnd/egl_vendor.d/50_mesa.json which is probably the issue
(In reply to seb128 from comment #10) > Ok, I figured it out, it's a problem due to apparmor, I didn't know surf was > including an apparmor profile Hah! Nice, good job. And now we understand why it wasn't a problem on Debian or Fedora. I'll use the "MOVED" resolution status here to indicate the bug report needs to move somewhere else.