In recent F33 updates-testing builds of Firefox, there seems to be a problem which causes various interface elements to take a very long time to respond to input, when running in KDE at least (possibly GNOME too, haven't tested yet). I noticed this as it causes openQA test to fail almost every time, but it also reproducible manually: 1. Install a fresh F33 KDE VM (mine is virt-manager using virtio and SPICE graphics) 2. Run Firefox, check it behaves more or less normally when you type in the URL bar or open about:config 3. Update Firefox from updates-testing, run it again, and again try typing in the URL bar or opening about:config For me, typing in the URL bar or doing almost anything in about:config means I have to wait 30 seconds or so after every input to get any kind of visual response. For that whole time the app appears frozen. However, if I type a URL blind and hit enter Firefox immediately "wakes up" and loads that URL. But while I was typing, nothing I typed actually appeared in the Firefox window. Note, setting gfx.webrender.force-disabled to true does *not* seem to help at all with this. I don't think this is affecting F34 or Rawhide, but I will test that as well as testing Workstation after lunch.
Confirmed this doesn't affect Workstation on F33 or KDE on F34. It seems specific to KDE on F33.
Can you please attach content of about:support from the broken FF instance on KDE/F33? I suspect this is X11 / Basic rendering (WebRender is off), I'm quite puzzled what could happen there. Thanks.
Adam, is the OpenQA testsuite running exclusively on KDE? Or do you also test on Gnome/Wayland? I'm already running mozilla internal tests on Wayland/Gnome, I guess it would be great to integrate it to OpenQA too.
We test on both. The test in question is "does the default desktop browser start and work?", for both of our release-blocking desktops; it's an automation of https://fedoraproject.org/wiki/QA:Testcase_desktop_browser .
So we discovered some relevant details about this today. It turns out there's another bug involved here, though there probably still is some kind of real Firefox bug. Basically: we found out that in the openQA test, and also in my reproducer scenario, KDE is running on Wayland. That's not supposed to be the default in Fedora 33. But it seems like if you do a network install of F33 and select the KDE environment, you get KDE-on-Wayland as the default session. We're not sure if this was also the case at release time, or if it's only happening now due to some change in the updates repository. If you install the F33 KDE live image and then update the system, you don't get a KDE on Wayland session by default. So there is some difference there. This bug only happens when KDE is running on Wayland. When KDE is running on X.org, Firefox works fine. So, I think it's still a bug that the older Firefox build is fine in KDE-on-Wayland-on-F33 but the newer one is not. But it's probably a slightly less important bug than I thought, since *probably* most people installed from a live image and so hopefully should be running KDE-on-Xorg, not KDE-on-Wayland. I will file a separate bug for the "getting KDE-on-Wayland by default" issue and try to investigate what's causing it. I'm not sure if we should count this bug as serious enough to hold up the Firefox update for F33 or not, mstransky WDYT?
I think we should not hold the update. If we get any Firefox/KDE/Wayland/Fedora33 related bugreports I can disable Wayland for F33/KDE only.
OK. However, you won't be able to push the update for now (unless you submit a waiver) as it looks like openQA gating just got enabled in production! I am going to look into why we're getting Wayland as the default session soon and file a bug; once I figure it out I'll probably adjust the openQA base image build process somehow so it tests on X, not on Wayland, and re-run the test which should hopefully pass at that point, unblocking the update.
OK, I tweaked the openQA base disk image so it uses X not Wayland, and re-ran the test. It's passed now, and the update is pushable.
Great, Thanks!
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Well, F34 is wayland by default and doesn't have this problem, so I guess we can let this die with F33.
Fedora 33 changed to end-of-life (EOL) status on 2021-11-30. Fedora 33 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.