This component is maintained by the GNOME project. Issues with it should be reported directly to GNOME at https://gitlab.gnome.org/GNOME/.

This issue should only be kept open if it:

1. Relates to Fedora packaging or integration with other Fedora components
2. Is required for Fedora release processes, such as blocker bugs and freeze exceptions

If this issue isn't needed for either of these two reasons, please:

 * create an issue with GNOME
 * add a link to the GNOME issue here
 * close this issue as CLOSED/UPSTREAM

Thank you!

In the F39 build https://bodhi.fedoraproject.org/updates/FEDORA-2023-9de52d46bd , there is /usr/share/applications/firefox.desktop but I don't see the problem Adam is seeing in Rawhide. Does the problem not affect F39?

This seems appropriate for downstream as it seems like a distro-level thing. Somebody please look at it.

Andre: the bug doesn't happen in openQA on F39 either. I figure the change is specific to Rawhide.

Should be fixed in gnome-shell-45.2-3.fc40

Well, the problem is that's also now blocked in gating because it has the same bug, because neither package gets tested together with the *other* package.

When you need to change things in two packages at once, you should do the builds on a side tag and create a combined update, so the changes properly get tested together. Now I'll have to either hack up a test of both together to verify they actually work, or just trust that they work and waive the failures, which will be a problem if it turns out they *don't* actually work together.

hacked-up test: https://openqa.stg.fedoraproject.org/tests/3425584#live . if that passes I guess I'll waive one update and re-test the other.

Now it looks like the launcher icon is there, but Firefox failed to run. Will look into it.

(In reply to Adam Williamson from comment #6)
> Well, the problem is that's also now blocked in gating because it has the
> same bug, because neither package gets tested together with the *other*
> package.
> 
> When you need to change things in two packages at once, you should do the
> builds on a side tag and create a combined update, so the changes properly
> get tested together. Now I'll have to either hack up a test of both together
> to verify they actually work, or just trust that they work and waive the
> failures, which will be a problem if it turns out they *don't* actually work
> together.

Adam, I'm sorry I caused you such troubles, didn't know how to release both packages together in rawhide.
Will ask you next time to prevent it.

If there's any issue remaining I can look at it.

Yes, there is still a problem, as you can see from the test result - now we see the launcher, but clicking it doesn't seem to actually start Firefox. I can't immediately see any indication of why in the logs ( https://openqa.stg.fedoraproject.org/tests/3425590/file/desktop_browser-var_log.tar.gz ). I can look into it more tomorrow, or you can try it locally in a VM, I guess.

To do a combined update for Rawhide you just follow the instructions at https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#multiple_packages .

Yes, updating my VM for testing, Thanks.

Yes I can reproduce it too.

It's caused by DBus activation flag. I'd need to implement DBus for that first. Reverted the flag in -3 build.

Hm, rawhide Firefox build fails with:

DEBUG util.py:446:  Error: 
DEBUG util.py:446:   Problem: conflicting requests
DEBUG util.py:446:    - nothing provides startup-notification{?_isa} = 0.12-27.fc40 needed by startup-notification-devel-0.12-27.fc40.x86_64 from build
DEBUG util.py:448:  (try to add '--skip-broken' to skip uninstallable packages)

That's a typo in https://src.fedoraproject.org/rpms/startup-notification/c/4d163823ad4853f5656dfef9d77de86fde9f5003?branch=rawhide - missing % symbol - whose commit message is a filthy lie. I'll fix it.

Fix is building. Run:

koji wait-repo f40-build --build=startup-notification-0.12-28.fc40

and when that returns, you should be good to go.

OK, -3 got built now it seems, so testing that together with gnome-shell now.

OK, that looks good. Will waive one and get them out.

agh, crap. I didn't test them against KDE, and it looks like Firefox now doesn't show up in KDE's menus:

https://openqa.fedoraproject.org/tests/2324503#

Going to have to get both builds untagged.

Haven't we been through this whole process once before, now I come to think of it?

Filed KDE bug at https://bugzilla.redhat.com/show_bug.cgi?id=2256443.

*** Bug 2255874 has been marked as a duplicate of this bug. ***

BTW, I am still seeing problems on GNOME in current Rawhide. In the app switcher and overview, the icon used for Firefox windows is not Firefox's proper icon but a generic "two cogs in a blue diamond" icon. And when I click a link from another application, it does not open in Firefox - which is configured as my default browser - but in Epiphany, which I'm pretty sure is likely caused by this too.

I'm unable to reproduce on latest Rawhide. Works fine even in KDE.

Well, I don't know what to tell you, it's 100% reproducible here. Have quit and restarted Firefox several times, and rebooted. Still behaves the same. This is with firefox-121.0-3.fc40.x86_64 and gnome-shell-45.2-3.fc40.x86_64 .

Created attachment 2007356 [details]
firefox showing blue cog icon

I can reproduce: I get the wrong icon, see attached screenshot. (When clicking on a link, firefox is started, not epiphany, but this VM doesn't have epiphany installed.)

(In reply to Zbigniew Jędrzejewski-Szmek from comment #25)
> Created attachment 2007356 [details]
> firefox showing blue cog icon
> 
> I can reproduce: I get the wrong icon, see attached screenshot. (When
> clicking on a link, firefox is started, not epiphany, but this VM doesn't
> have epiphany installed.)

I do see that too now. No idea why it worked before.

Should be fixed by firefox-121.0.1-2.fc40

Yeah, confirmed, thanks. Also my default app had somehow changed in GNOME settings, and changing it back solved that problem. I can't 100% blame that on Firefox as GNOME stuff was changing in Rawhide at the same time, so maybe it's just coincidence that it seemed to break at the same time as this.