Its even worse when you force Firefox to use wayland its icon doesn't even show.
Edit: Oh since everyone now is confused; I only have the flatpak version of Firefox installed yet it doesn't use the pinned icon and doesn't even use the firefox icon under wayland at all.
Don't know about the OP, but I only have one version installed. If I don't have it open, a single icon shows on the task bar. If I press that icon, FF opens and a second icon shows up, that represents only the opened FF, while the original icon remains.
In that particular screenshot I believe you’re right: the one on the left is Firefox ESR while the icon on the right is whatever flatpak version available.
But I know what OP is referring to as it is a open bug currently, the DE don’t doesn’t recognize the launched instance as the pinned program due to the way Flatpak launched apps. Not an issue with Firefox in particular
No no I only have the flatpak version of firefox installed yet in my taskbar it doesn't use the pinned icon and on wayland it doesn't have an icon at all.
I use the Firefox flatpak on multiple different desktops and distros and I've never seen this issue. All on wayland (no difference on x11 either). Weird.
i have no issues with flatpak, once i found out how to fix gtk scaling and theming issues on kde. here's a link if anyone has those problems as well https://bugsfiles.kde.org/attachment.cgi?id=135846.
I'm using KDE + Firefox Flatpak + Papirus Icons and I haven't had this issue (so far). Could it be an icon pack issue or something similar? Otherwise yeah it's either KDE or the flatpak
To start you off: $ bwrap --dev-bind / / --tmpfs ~ bash
This basically gives you a shell in a clean virtual home directory (but no meaningful security improvement yet). You can test new builds of software as if you have only the default settings. If you need to access files, move them to /tmp/.
To see the clean virtual home directory, replace --tmpfs ~ with --bind "$(mktemp -d)" ~. You can browse it where mktemp puts it (usually /tmp/*).
To start to lock down security, replace the --dev-bind with --ro-bind, and add various --new-session, --uid/--gid, and --unshare-all/--unshare-* flags. You can run untrusted and semi-trusted/less-trusted applications with less security risk this way (as long as you're aware of pitfalls, such as the /tmp/.X11-unix/X0 socket and other possible avenues of escape).
To block network access, use --unshare-net or --unshare-all. To virtualize /dev and /proc, use --dev /dev and --proc /proc.
Some programs might need --dev-bind /dev/dri /dev/dri for graphics driver access, or similar constructs.
EDIT: …I actually created a way to create completely portable application executables for Linux by using bwrap (or proot, as a fallback) to virtualize a Nix root from inside an AppImage, earlier this year. bwrap offers a lot of granularity in modifying and containing the virtual environment, to the degree that you can basically emulate an entire guest OS/distro on top of the host distro, without even needing root privileges— And without even needing bwrap itself to be installed, since it can work using entirely standard Linux kernel features.
I never intend to use a flatpak or snap, and avoid them like the plague. The whole concept is incredibly ugly to me, and wasteful of computer resources.
Depends on the viewpoint. As a software consumer, sure. As a software producer though, not having to deal with with tons of different packaging formats and repositories for different distributions and versions is a blessing.
It wastes resources on the consumer side to free up resources on the developer side, allowing for more time spent on improving the software instead of worrying about millions of different system setup combinations.
Am a developer and I can very much agree on package managers have nasty configuration, but at the same time flatpak is the exact same thing. No different that any other package. Except now you have to learn yet another standard that's even less popular than major ones. You can even claim it's easier, but the fact remains it's not the defacto standard, so you still have to provide other packages as well as flatpak if you wish to do so.
the scuffed difference between my normal theming and flatpak theming is the only reason why I despise flatpak. I cannot for t he life of me get it to do what I want it to do. Flatpak containers are also kinda annoying to access
the only reason to use flatpaks is if your system doesnt come with a good package manager and repositories (pacman+aur, nix, etc), and dont want to build from source.
snaps, on the other hand, should be avoided at all costs imo.
Tied to proprieatry backend, snap store looks like ass and runs like one, spawns loop devices that mess up the /mnt folder, tied to fake .deb packages that install snaps instead. Basically, a lot of proprieatry nonsense that St. Ignucius frowns upon.
Haven't had this issue on Gnome, might be a KDE specific issue. I really don't use KDE much except on my Steam Deck so I haven't encountered it very often.
"hey guys, I'm having a problem with my Linux install that doesn't seem very common--"
"YOU'RE STUPID AND I HATE YOU"
this is EXACTLY why Linux gurus have a bad rep. remember the human, for goodness' sake. don't act like you've never run into a strange problem in your entire computing life that required digging deep into some 2003 forum post to solve.
Please show me the QA process applied to flatpaks, so I know that besides it “working” is not full of obsolete vulnerable holes. Or should I just trust the Dev is not a lazy person?