Bug 2319081

Created attachment 2052262 [details]
Firefox icon present on 20241013 nightly compose.

See how we have utilized the Firefox launcher to start desktop browser as late as on 20241013.

Created attachment 2052263 [details]
Firefox icon absent on 20241015 nightly compose.

Yet, on the next compose 20241015, it is no longer there.

Proposed as a Freeze Exception for 41-final by Fedora user lruzicka using the blocker tracking app because:

 They took our icon away, we want it back.

Oddly enough, the patch that sets the favorites is still there: https://src.fedoraproject.org/rpms/plasma-desktop/blob/rawhide/f/plasma-desktop-5.90.0-default_favorites.patch

Created attachment 2052316 [details]
Screenshot of Kickoff with Firefox from the Oct 15 test image

So I just downloaded and installed the October 15 image, and I cannot reproduce the issue. The attached screenshot demonstrates it's there as expected.

it seems to be an intermittent bug. sometimes it's there, sometimes it isn't. It's actually been happening for a while, but the openQA "retry once on failure" mechanism has been saving us from noticing. The earliest occurrence I can find seems to be https://openqa.fedoraproject.org/tests/2917970 , 15 days ago, but it's getting much more common recently. I suspect it's tied to the whole "KDE just seems slow and flakey in openQA lately" situation. You can get a feel for it by looking at the "Next & previous results" tab on openQA. https://openqa.fedoraproject.org/tests/2957276 is the most recent incidence of this bug. If you go to its "Next & previous results" tab and expand the view to 100 runs per page, you can really get a feel for it.

The first page has lots of failures - almost all of which are this bug, you can tell by looking at the failure thumbnail - and all the passes are actually softfails (orange) because firefox takes a long time to start up (if it takes more than 45 seconds from clicking on the launcher for Firefox's UI to be fully loaded, openQA marks it as a soft fail). The second page has fewer failures, and you can see right around 2024-10-04 is where the oranges kick in, before that it's nearly all greens. Page 3 has a cluster of failures from a network outage, but otherwise is nearly all green. Page 4 (as I write this) is all green.

You can see the exact same pattern on staging (start at https://openqa.stg.fedoraproject.org/tests/4342044 there), so this doesn't look like it's openQA that's gone weird, it really seems like KDE has been degrading lately.

oh, and if you check next/previous for the GNOME test - start at https://openqa.fedoraproject.org/tests/2957292 - it's a symphony of green, so this is definitely KDE-specific.

The onset of these issues looks like it matches quite neatly with when the 6.2.0 final megaupdate landed: Fri Oct  4 08:51:10 2024 kwin-6.2.0-1.fc42 tagged into f42 by bodhi . so possibly this was introduced by something between 6.1.90 and 6.2.0.

The same story holds with other tests, e.g. desktop_printing - start at https://openqa.fedoraproject.org/tests/2957266 . The next/previous view has a *ton* of red back to a failure on FEDORA-2024-0a1e0076d2 at 10:29 on 2024-10-04; before that, it's almost all green.

Oh hey. So this is probably just because https://bugzilla.redhat.com/show_bug.cgi?id=2312900 came back. I'm fixing that now.

*** This bug has been marked as a duplicate of bug 2312900 ***

Hum. In https://openqa.stg.fedoraproject.org/tests/4347778#step/desktop_browser/27 , this happened on kwin-6.2.1.1-1.fc42 , which seems concerning :(

It's not a *ton* of data, but since openQA started picking up the fix for the performance issue yesterday, results for desktop_printing (which doesn't go through Favorites) are 100% green on prod and stg, but results for desktop_browser (which does go through Favorites) have three fails on stg and one on prod. So it kinda looks like this was indeed broken by the 6.2.0 update, but it's *not* just a symptom of the performance issue.

+4 in https://pagure.io/fedora-qa/blocker-review/issue/1704 , marking accepted FE.

Just to confirm, this definitely has kept happening and was not part of the performance bug and is still happening. It's still causing tests to fail periodically, which is a PITA :|

This is still happening, and still a PITA.

This should help fix it, since it resolves the race that occurs when this runs for first login: https://src.fedoraproject.org/rpms/xdg-user-dirs/pull-request/4

FEDORA-2025-6905d9518a (xdg-user-dirs-0.18-7.fc40) has been submitted as an update to Fedora 40.
https://bodhi.fedoraproject.org/updates/FEDORA-2025-6905d9518a

FEDORA-2025-ac891d77a9 (xdg-user-dirs-0.18-7.fc41) has been submitted as an update to Fedora 41.
https://bodhi.fedoraproject.org/updates/FEDORA-2025-ac891d77a9

FEDORA-2025-6905d9518a has been pushed to the Fedora 40 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-6905d9518a`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-6905d9518a

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2025-ac891d77a9 has been pushed to the Fedora 41 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-ac891d77a9`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-ac891d77a9

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2025-6905d9518a (xdg-user-dirs-0.18-7.fc40) has been pushed to the Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2025-ac891d77a9 (xdg-user-dirs-0.18-7.fc41) has been pushed to the Fedora 41 stable repository.
If problem still persists, please make note of it in this bug report.