Bug 2187442 - yelp shows no content with webkitgtk 2.41.2
Summary: yelp shows no content with webkitgtk 2.41.2
Alias: None
Product: Fedora
Classification: Fedora
Component: webkitgtk
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Michael Catanzaro
QA Contact: Fedora Extras Quality Assurance
Whiteboard: openqa
Depends On:
Blocks: F39FinalBlocker
TreeView+ depends on / blocked
Reported: 2023-04-17 17:23 UTC by Adam Williamson
Modified: 2023-04-21 01:47 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2023-04-21 01:47:42 UTC
Type: ---

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
WebKit Project 254807 0 None None None 2023-04-17 17:23:45 UTC

Description Adam Williamson 2023-04-17 17:23:30 UTC
User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/112.0
Build Identifier: 

Since webkitgtk 2.41.2 landed in Rawhide, yelp (the GNOME help viewer) never shows any content. When run from a console, these errors are shown:

libEGL warning: egl: failed to create dri2 screen
KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied
Failed to create GBM buffer of size 1280x721: Permission denied
KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied
Failed to create GBM buffer of size 1280x721: Permission denied
Failed to create EGL images for DMABufs with file descriptors -1 and -1

The problem can be worked around by running `WEBKIT_DISABLE_DMABUF_RENDERER=1 yelp` - in that case, no messages are shown, and the help content is visible.

Reproducible: Always

Steps to Reproduce:
1. Ensure you have webkit2gtk4.1-2.41.2-1.fc39 and yelp installed.
2. Run yelp.
Actual Results:  
You get a blank window.

Expected Results:  
You should get a window with some help content.

This is very similar to upstream https://bugs.webkit.org/show_bug.cgi?id=254807 , but that report claims it only affects multiple GPU cases; for me, the problem reproduces in a libvirt VM with virtio graphics, no multiple GPUs required.

Comment 1 Adam Williamson 2023-04-17 17:25:20 UTC
Proposing as an F39 Final blocker as a violation of https://fedoraproject.org/wiki/Fedora_38_Final_Release_Criteria#Installer_help - "Any element in the installer interface(s) which is clearly intended to display 'help' text must do so correctly when activated."

Comment 2 Adam Williamson 2023-04-18 00:28:16 UTC
We're hoping https://koji.fedoraproject.org/koji/buildinfo?buildID=2188308 will fix this when it's finally done.

Comment 3 Adam Williamson 2023-04-18 06:09:08 UTC
OK, fix confirmed. The aarch64 build seems to be stuck for some reason, though. Checking with CPE on that.

Comment 4 Michael Catanzaro 2023-04-18 12:58:49 UTC
That's expected. We have extremely limited build capacity for aarch64 and it can take a day or two to get scheduled if there are Chromium jobs in progress. Just got to be patient. Other architectures are in good shape.

Comment 5 Adam Williamson 2023-04-18 15:14:12 UTC
Lately we actually are supposed to have much more capacity for aarch64, we put more powerful builders online. These days my aarch64 jobs usually finish first out of all arches.

Comment 6 Adam Williamson 2023-04-18 15:18:00 UTC
Per nirik the problem is the invention of a "heavybuilder" channel for big packages: there are two "heavybuilder" boxes for aarch64, and six builds in the queue (five chromium builds, and this webkitgtk build). Fun.

Comment 7 Michael Catanzaro 2023-04-18 15:19:30 UTC
Yes, problem is we kept hitting OOM errors last year when using wimpy builders. I'd much rather wait for the build to be scheduled and see it complete reliably than go back to the OOM lottery. The status quo is slow but at least it's stable.

Comment 8 Adam Williamson 2023-04-21 01:47:42 UTC
This finished a couple days back, fix is all good.

Note You need to log in before you can comment on or make changes to this bug.