Will the Firefox snap run in WSL2 out of the box with 22.04?
I was curious about the impact on UX and ran some tests in a virtual machine.
VERSION_ID="21.10" VERSION="21.10 (Impish Indri)" Name Version Rev Tracking Publisher Notes bare 1.0 5 latest/stable canonical✓ base core 16-2.52.1 11993 latest/stable canonical✓ core core20 20211129 1270 latest/stable canonical✓ base firefox 96.0-2 838 latest/stable/… mozilla✓ - gnome-3-38-2004 0+git.cd626d1 87 latest/stable/… canonical✓ - gtk-common-themes 0.1-59-g7bca6ae 1519 latest/stable/… canonical✓ - snap-store 3.38.0-66-gbd5b8f7 558 latest/stable/… canonical✓ -
- About 12 GB of RAM allocated to the VM.
- I used a Firefox profile for load testing with 14 open windows and a total of 10,480 open tabs.
The whole system had a peak of about 6.9 GB and it settled at around 5 GB of RAM.
All plugins and the custom theme were loaded without problems. All active tabs loaded with their sessions working and displaying all pages correctly (including last viewport scroll position).
At some point in the past, Mozilla decided to change the default setting of
false. Closing one window with 3,000+ tabs used to display a confirmation message. I thought I’d mention it, but that’s sadly not the first time Mozilla screwed their user base.
Now the comparison with the Debian package.
sudo snap remove firefox sudo apt install firefox
95.0.1+build2-0ubuntu0.21.10.1 started significantly faster (maybe 50 % of the snap’s startup time) but startup time has already been discussed and is probably not a fair comparison anyway. Additionally to comparing different versions 96 vs. 95.
Memory usage is higher: 8.4 GB max during startup and 5.7 GB after settling. This is also an interesting result. The profile / session was restored in the same way without any issues.
Overall I am very impressed with the stability of cramming this program into a snap. I expected a total crapfest and your mutilated version took the profile like a champ. So in terms of stability it seems pretty solid. Maybe this change will not annoy enough users this time.
Thanks Bernard, appreciated! Congratulations for advancing from translator to software architect, my man.
Thank you for keeping this on track. With your help this will be an achievable transition. Canonical can be glad to have staff like you on payroll.
This hasn’t been tested yet, but if you do, please share your experience here!
“mutilated” isn’t how I would have qualified it, but thanks for testing and for the overall positive feedback, this is much appreciated!
As far as I know, snapd depends on systemd, but WSL2 is currently not using a real systemd.
My use case is to use the “Ubuntu” Firefox from within WSL2 to manage some oVirt installations and use the virt-viewer.
And I think with the license change of “Docker for Windows”, there are also other use cases to get a running snapd or systemd on WSL2.
I’m experiencing very slow startup times with Firefox as Snap compared to FF as Deb. As a testcase, I started both variants after booting without launching any other applications (“cold start”), compared with starting them when they had been already running (“warm start”). To rule out outliers, I did more than one run for each test (rebooting three times):
Snap cold start: 20 | 23 | 19
Snap warm start: 8.8 | 9.9 | 9.8 | 10.1
Deb cold start: 3 | 3.2 | 3.2
Deb warm start: 2.2 | 2.3
All times in seconds.
My test setup/system:
- Kubuntu 22.04 Plasma Wayland session
- fresh Firefox profiles
- Intel Core2Quad Q9550
- 8 GB RAM
- SSD drive
Any chance this will get better or be fixed until the final release?
Kind regards, Jan
This is consistent with the observations in bug #1748076.
Apart from the known overhead caused by snapd’s confinement, it has been suggested that shipping all langpacks inside the snap might cause a significant slowdown at startup. This needs to be investigated and confirmed.
That does not sound plausible to me. I have a Debian testing installation, where all the
firefox-esr-l10n-* packages are present. Firefox still starts fast.
I am getting to dislike snaps more and more. Almost all apparmor problems I have come from snaps. Not easy to fix. And snaps make using commands like df a pain to get through all tge meaningless cruft that snaps create.
Guys, I get all the motivations behind the decision to drop debs, and I’m of course aware that snaps are a Canonical invention and that Canonical would like to promote its own technology… but come on guys, this decision to only distribute firefox as a snap is going to hit your users and it’s going to damage the overall ubuntu desktop experience. 20 seconds to start your default internet browser is an insane amount of time, expecially when the flatpak based version of Firefox doesn’t have this kind of issue. Please guys be reasonable: if you can’t afford to mantain and support many versions of the same .deb package, please join the flatpak team. There’s really no reason to make people distro hop.
Snaps on the desktop are clearly showing some problems. You don’t have to drop the standard, but please understand that until snaps have comparable performances to their deb and flatpak counterpart, they will not be accepted by the users.
Please don’t receive this as a yet another anti-canonical comment. I really like the company… and I understand the reasons behind snaps. I’m spending time to say this because I care about ubuntu and I really would like it to be successiful.
Ubuntu 22.04 has Wayland session by default. Firefox should work on Wayland like in xorg.
Yes that’s a big issue atm.
This one has appeared then was solved after I reported in Bugzilla (maybe in v96) but appeared again.
Bookmarks menus are globally buggy, e.g. contextual menu is displayed outside of the display:
(here at the bottom of my screen)
These bugs are by far not hidden.
Is there a way to install Firefox snap from both stable and beta channels?
I currently have the beta one installed as a snap, and it crashes very frequently, even with
snap set core experimental.refresh-app-awareness=true.
Also, any plans on adding touch features on the snap?
sure … snaps allow as many parallel installs as you like:
Maybe a very annoying bug will be solved?
(see last message)
That’s medium-categorized. I’m by far not an expert but this one (or rather the whole background-update issue, maybe?) is a damn critical bug since your TB or FF will crash during your work.
Just today I lend a recently jammy-upgraded laptop to a colleague because he needed to use FF. Gmail and so on and… “hey Francois, it crashed”. Well, that’s no good for Ubuntu or Linux image…
To be positive, the solution I do use is:
- install the incredible Snap Manager Lite extension : https://extensions.gnome.org/extension/4889/snap-manager-lite or old Snap Manager extension (with arrow on the icon… and available update notifications, that I did remove from Lite version)
- Menu Refresh options > Hold auto refresh for one month
- Then do the updates by yourself, either using the extension or Snap Store or GNOME Software
No more crashes…
I’ve been a fan of Snaps, however the FireFox snap has been crashing on me 5+ times a week since I’ve installed it with 21.10 in October. It has also completely broken 4 times where even a purge uninstall then reinstall wouldn’t fix it. It would not connect to the internet at all and would fill up 10GB of space on my disk.
have you enabled the refresh-app-awareness option (which is the default in 22.04) from above to prevent apps being updated while they are running ?
Same for me, and I do have it enabled.
No not manually, I had thought this was default behavior already.
Regardless it looks like it doesn’t work correctly yet according the the bug linked above.