https://bugs.kde.org/show_bug.cgi?id=394577
Chad Joan <chadj...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|WORKSFORME |FIXED
--- Comment #3 from Chad Joan <chadj...@gmail.com> ---
Problem seems fixed after removing the
~/.local/share/applications/firefox.desktop file.
Specifically, I moved it to a backup file like so:
cd ~/.local/share/applications
mv firefox.desktop firefox.desktop.bak-2018.11.19
It took me a while to revisit this problem, but inspiration hit: I think Eike's
mention of /opt being odd and an incorrect .desktop file were the hint I
needed. The contents of the firefox.desktop file looked like this:
[Desktop Entry]
Exec=/opt/firefox/firefox
Icon=application-x-executable
Name=firefox
Type=Application
This seems a likely candidate for explaining why plasma was looking for the
/opt/firefox/firefox file that did not exist (the /opt/firefox directory also
doesn't exist).
I'm not sure I understand specifics about the mechanisms involved, but I can
see how telling KDE/plasma to open a non-existent executable might confuse it.
Or perhaps the .desktop was outdated and accidentally overrode metadata from
more well-updated system files. Whatever the possibilities, that file seemed
like a source of problems, and removing it fixed this problem.
I'm also not sure how I ended up with the state in the first place. Maybe
Firefox really did live in /opt/firefox/firefox at one point in history, and
then an upgrade at some point moved it elsewhere, but without updating the
.desktop file (and it's hard to expect a package manager or install script to
always perfectly handle updates to user configuration). Maybe these are
remnants of some workaround from days past. I'm not too worried about it
because of how isolated this seems.
Thanks for the help Eike Hein!
--
You are receiving this mail because:
You are watching all bug changes.
