Setting Firefox (Snap) as the default internet browser on Linux doesn't work when its `.desktop` file doesn't exist.
Categories
(Firefox :: Shell Integration, defect, P2)
Tracking
()
People
(Reporter: zn7esutb, Unassigned, NeedInfo)
References
Details
Attachments
(2 files)
Non-existent `.desktop` file presence hallucination.
Initial Environment
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/119.0
Steps to reproduce
I installed:
#!/usr/bin/env sh
sudo snap refresh
sudo snap install --channel=latest/edge firefox
snap run firefox -setDefaultBrowser
...and attempted to set it as the default browser.
Actual results
-
-
See attached image - Firefox hallucinates that a
.desktopfile exists, when one doesn't. Additionally, when the prompt is accepted, Firefox remains not the default browser.
Expected results
Firefox should have created a .desktop file for itself (if necessary). Regardless, it should have set itself as the default browser.
|
Reporter | |
Comment 1•2 years ago
•
|
||
id=1852554#c49Because there's no
.desktopfile for firefox on this system, I have to run firefox using snap run firefox. Despite that, when I'm using it, an icon appears in my task(bar/manager) correctly, which I can pin and drag to my desktop, creating a formerly considered to be erroneous.desktopfile acting as a URI rather than path invoker, but with the path/snap/firefox/3182/usr/lib/firefox/firefoxsupplied. If I invoke this "incorrect" version, it indeed is able to set itself as the default scheme handler, despite there being no obvious.desktopfile. Perhaps my conclusion thus that the lack of a desktop file is the cause is erroneous, but gee this is confusing.
I might actually be correct about the latter part, because by pinning it and/or dragging it to the desktop, a .desktop file is indeed created in $HOME/.local/share/plasma_icons.
|
|
Reporter | |
Comment 2•2 years ago
•
|
||
|
|
Reporter | |
Updated•2 years ago
|
|
||
Comment 3•2 years ago
|
||
| resolved | ||
The Bugbug bot thinks this bug should belong to the 'Firefox::Shell Integration' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
| Comment hidden (duplicate) |
|
||
Comment 5•2 years ago
|
||
Hello, thank you for the bug report!
Tested your issue on Ubuntu 22, with latest nightly Firefox snap build from 2023.09.25, yes indeed the first message appears, but accepting the prompt (clicking on "Yes"), Firefox become the default browser, as your about:preferences shows.
Would you be so kind to test it again and see if I am wrong or I missed something?
|
|
Reporter | |
Comment 6•2 years ago
•
|
||
yes indeed the first message appears, but accepting the prompt (clicking on "Yes"), Firefox become the default browser, as your about:preferences shows.
#a904_691781 explains why.
Reproduce using the --edge snap on openSUSE-Tumbleweed-NET-x86_64-Current.iso if it's not working on Ubuntu, or perhaps just try deleting the .desktop file (that should work unless I've misattributed the problem).
|
|
||
Comment 7•2 years ago
|
||
The severity field is not set for this bug.
:mpohle, could you have a look please?
For more information, please visit BugBot documentation.
|
||
Updated•2 years ago
|
|
|
||
Updated•2 years ago
|
|
|
||
Comment 8•2 years ago
|
||
@ jlorenzo@mozilla.com Should this be higher priority / on a different team?
|
||
Comment 9•2 years ago
|
||
Thanks for the needinfo, Michael!
Hey :bandali! I'm sorry, I don't remember, Canonical provides a .desktop file in the Firefox Snap package you all build, right? If so, any idea what could cause the issue?
|
||
Comment 10•2 years ago
|
||
I've been experiencing this for several recent stable versions of Firefox snaps. Running Ubuntu 22.04.03 LTS. Clicking make default doesn't work here either. I was updated to v122.0 today and it caused a 10x CPU usage increase in a specific webpage which brought me to this bug site. I removed v122 and switched to the esr channel - now at v115 and no usage issues but make default doesn't work here either.
|
|
Reporter | |
Comment 11•2 years ago
•
|
||
Because you state that it might be relevant, have you tried firefox-source-docs.mozilla.org/performance/reporting_a_performance_problem.html#enabling-the-profiler-toolbar-button (if the performance issue you describe is reproducible)? It's more useful than even a detailed anecdote.
|
|
||
Comment 12•2 years ago
|
||
Didn't know about that...I'll do that and post back. Thanks.
|
|
Reporter | |
Updated•1 year ago
|
|
|
Reporter | |
Updated•1 year ago
|
| Comment hidden (obsolete) |
|
|
Reporter | |
Comment 14•1 year ago
•
|
||
Clear a needinfo that is pending on an inactive user.
release-mgmt-account-bot, it's not critical, but a corroboration would have been useful (especially since I use F40 - not OSTW - now, nor the Snap package: the .RPM functions better). I can try to reproduce if nobody else can provide an account - if it does reproduce, that'll be useful, after all.
| Comment hidden (obsolete) |
|
|
Reporter | |
Comment 16•11 months ago
•
|
||
Clear a needinfo that is pending on an inactive user.
release-mgmt-account-bot merely generates noise. Whether they take even years to respond shouldn't affect anything. What disadvantage does retaining the NEEDINFOs cause? The bot is akin to GitHub's "Stale" one.
|
|
||
Comment 17•10 months ago
|
||
Redirect needinfos that are pending on inactive users to the triage owner.
:cdupuis, since the bug has recent activity, could you have a look please?
For more information, please visit BugBot documentation.
Description
•