Created attachment 1736626 [details] Koji website rendering broken I'm using falkon as primary browser in a virtual machine running Rawhide I use for development. I've noticed that some website, most notably Koji, are completely broken and unusable - see the attached screenshot. I've already tried to disable AdBlocker on the affected websites with no luck.
This is most likely a regression in QtWebEngine, reassigning. I also made the subject clearer: the issue appears to be that the text is not being rendered, only the images. (The only "text" in the Koji web site's page on your screenshot is actually part of the logo image.)
Actually, since this is a rendering issue, it could also be a graphics driver bug. What graphics hardware and driver are you using? Can anybody reproduce this on other hardware?
(You say the "hardware" here is a virtual machine, but what virtual machine? And does it have OpenGL passthrough? In that case, the host hardware also matters.)
It's a QEMU/KVM virtual machine, with Virtio video driver with 3d acceleration enabled and Spice monitor with OpenGL disabled. I've also tried to disable 3d acceleration and switch to QXL video driver, but the result doesn't change. The problem seems independent from the video driver used. Just use default settings from Virtual Machine Manager to create a Fedora rawhide machine.
Nominating as a blocker for F34 Beta under Basic Criterion 2.5.8 Required applications. If this is rejected, nominating as a blocker for F34 Final under Final Criterion 2.6.7 Default application functionality.
FYI, this has since also been confirmed in Chromium, and this mailing list thread: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/OK3ZF3554P4D5NUGW3BJMR2R7WONIFUY/#OK3ZF3554P4D5NUGW3BJMR2R7WONIFUY has some insights. Basically, it was tracked down to a sandbox issue affecting the Chromium code if it was compiled against glibc 2.23. We are not yet sure why the version used at compile time matters (because the syscall use changes are normally in the glibc .c files, not the headers) nor what exact syscall is being blocked by the sandbox.
> against glibc 2.23 2.33, actually
I'm trying to build a candidate fix (that I wrote) now: https://src.fedoraproject.org/rpms/qt5-qtwebengine/blob/master/f/qtwebengine-everywhere-src-5.15.2-%231904652.patch
Unfortunately, I cannot move forward because qt5-qtwebengine FTBFS due to a GCC or Gold issue: /usr/bin/ld.gold: warning: /usr/lib/gcc/x86_64-redhat-linux/11/../../../../lib64/Scrt1.o: unknown program property type 0xc0008002 in .note.gnu.property section /usr/bin/ld.gold: error: treating warnings as errors collect2: error: ld returned 1 exit status
The Binutils (gold) issue is fixed, resubmitting the qt5-qtwebengine build.
Can you please try qt5-qtwebengine-5.15.2-5.fc34? For now, you can get it from: https://koji.fedoraproject.org/koji/taskinfo?taskID=60219042 (The 2 ARM arches are still building, and then it will also take hours to get into an actual Rawhide compose.)
A first try seems not promising... I'm now fully upgrading my Rawhide VM, I'll post results later.
Do you have qt5-qtwebengine-freeworld installed? If yes, you need to uninstall it for now, until a fix is applied there too. If the candidate fix is not working, we will probably need to find a way to debug this further (which is quite hard, sandbox code is a pain to debug), unless upstream magically comes up with something that works.
qt5-qtwebengine-freeworld is not installed. I'm afraid that this qt5-qtwebengine update is completely broken, now I can't open any webpage. I tried with WebEngine Qt Quick Minimal Example from within QT Creator (https://doc.qt.io/qt-5/qtwebengine-webengine-minimal-example.html) and no page is displayed. In the application output tab it shows `../../3rdparty/chromium/sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0262` Falkon shows the same error message when started in console.
Thanks for your feedback. The build was still running on the ARM architectures, so I simply canceled it. Hence, the output should not end up in the Rawhide compose.
I think I know what is going wrong. I have revised the patch: https://src.fedoraproject.org/rpms/qt5-qtwebengine/c/09e1adb883639325aa8115dc1fc3e8f5088a2438?branch=master and I am building the revised candidate patch now: https://koji.fedoraproject.org/koji/taskinfo?taskID=60237992 I will let you know when there is a binary RPM to test.
Can you please try this version? https://koji.fedoraproject.org/koji/taskinfo?taskID=60238322
I tested this myself and it seems to work now! 1. fired up Fedora-KDE-Live-x86_64-Rawhide-20210120.n.0.iso in QEMU-KVM 2. started Falkon 3. opened https://koji.fedoraproject.org/koji/ 4. confirmed that text rendering (without the fix) is broken 5. closed Falkon 6. upgraded qt5-qtwebengine to the RPM from https://koji.fedoraproject.org/koji/taskinfo?taskID=60238322 7. reopened Falkon 8. opened https://koji.fedoraproject.org/koji/ 9. confirmed that text rendering is now working Mattia, can you please confirm that this is also fixed for you, so that I can close this (at least once the ARM arches are built, too)?
Yes, I've tested both Falkon and the qt5 creator example and both are working now. Thank you!