Bug 2187442

Summary: yelp shows no content with webkitgtk 2.41.2
Product: [Fedora] Fedora Reporter: Adam Williamson <awilliam>
Component: webkitgtkAssignee: Michael Catanzaro <mcatanza>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: rawhideCC: gnome-sig, mcatanza, peter, philip.wyett, tpopela
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: openqa
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-04-21 01:47:42 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 2143446    

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.