As many of you are aware, Firefox had discontinued support for web app installations; it may resume at some later date, but this is speculation at this point.
However, don’t let that discourage you.
There are workarounds to this. Although it’s a bit of a hack and doesn’t provide a seamless web app experience (there will be a title bar and no app management page, for example), I have written a guide to emulate the behavior of a true Firefox web application. This is performed by creating a dedicated Firefox profile for a website and placing an icon for the profile in the application gallery.
I’m open to suggestions to improve the guide if you find a better approach or if you discover a way to automate this. Feel free to leave comments here or on the snippet itself.
I actually made a similar script a few days ago but it is lacking in a number of features such as downloading and parsing any potential manifest data and providing a default desktop icon (possibly using the favicon as a source). It is probably possible to do these things using existing tools in a shell script but I feel it will likely become a messy script, which it already is.
Feel free to extend and fix issues with this script:
Usage:
ffpwa.sh # Requires `yad` package to be installed; a GUI will appear to enter the name, description, and the URL.
ffpwa.sh -D <profilename> # This will remove the `.desktop` and profile directory BUT you will also need to manually delete the profile from Firefox with the profile manager using the command `firefox -P`. There's unfortunately no way to automatically do this.
~/.local/bin/ffpwa.sh (You can rename this to whatever you want such as create_pwa.sh and even remove the file extension to make it easier to execute):
#!/usr/bin/env bash
#
# See: https://wiki.mozilla.org/Firefox/CommandLineOptions
PROFILES_LOCATION="${HOME}/.local/share/ffpwa/profiles/"
DESKTOP_ENTRIES_LOCATION="${HOME}/.local/share/applications/"
if [ -d "${PROFILES_LOCATION}" ]; then
mkdir -p "${PROFILES_LOCATION}"
fi
while getopts "D:" opt; do
case ${opt} in
D)
DELETE_PROFILE="${OPTARG}"
;;
esac
done
if [ -n "${DELETE_PROFILE}" ]; then
profile="${PROFILES_LOCATION}/${DELETE_PROFILE}"
desktop="${DESKTOP_ENTRIES_LOCATION}/ffpwa_${DELETE_PROFILE}.desktop"
rm -rf "${profile}" "${desktop}"
echo -e "Deleted profile files '${DELETE_PROFILE}' at '${profile}' and '${desktop}'\nYou MUST manually delete the profile from Firefox using \`firefox -P\` or by typing 'about:profiles' in a browser session."
exit 0
fi
res=$(yad --title="Firefox PWA" \
--separator="\t" --form \
--field="Name (No spaces):" "$NAME" \
--field="Description:" "$DESCRIPTION" \
--field="URL:" "$URL")
if [[ -n $res ]]; then
NAME=$(echo "${res[0]}" | cut -f 1 | sed 's/ /_/g')
DESCRIPTION=$(echo "${res[0]}" | cut -f 2)
URL=$(echo "${res[0]}" | cut -f 3)
if [[ -z ${NAME} || -z ${URL} ]]; then
echo "A name and URL must be provided!"
exit 1
fi
echo -e "You entered:\n\tName: ${NAME}\n\tDescription: ${DESCRIPTION}\n\tURL: ${URL}"
firefox -CreateProfile "${NAME} ${PROFILES_LOCATION}/${NAME}"
echo -e "Firefox profile created at '${PROFILES_LOCATION}/${NAME}'"
# Create a desktop entry (Linux).
DESKTOP_ENTRY_LOCATION="${DESKTOP_ENTRIES_LOCATION}/ffpwa_${NAME}.desktop"
cat > "${DESKTOP_ENTRY_LOCATION}" <<EOF
[Desktop Entry]
Type=Application
Version=1.0
Name=${NAME}
Comment=${DESCRIPTION}
Keywords=;
Categories=GTK;WebApps;
#Icon=
Exec=firefox -P "${NAME}" "${URL}" %u # --kiosk
MimeType=
Terminal=false
StartupNotify=true
X-Purism-FormFactor=Workstation;Mobile;
EOF
echo -e "Desktop entry created at '${DESKTOP_ENTRY_LOCATION}'"
fi
Regarding the Exec=firefox -P "${NAME}" "${URL}" %u # --kiosk line, you may want to enable the --kiosk mode to run the “app” in full screen mode when it launches.
I think if I want to make the app/script more flexible, I might need to create a CLI app with a proper programming language instead of a shell script.
To make the configuration automatic, you can create a user.js file in the profile directory. The arkenfox user.js project has a good number of configurations for reference but the entire arkenfox configuration file is likely not suitable for this purpose if taken as-is.
I’m using that on my Windows machine for installing ProtonMail webmail as separate app. I haven’t tried it on PureOS, but at least the project has deb packages available.
That extension/native app works, even on the Librem 5. I removed the guide from the Librem 5 wiki, though it can work if you manually download Firefox. Librewolf stopped producing native binaries, opting for AppImages and Flatpak.
I was tinkering with this yesterday and was able to get if to work by duplicating the firefox-esr directory that comes with PureOS on the Librem5 (had to fix permissions and symlink firefox-esr to firefox to get it to work. Hopefully its a safe setup lol).
The good news is firefox web apps work, icons look great, slight performance increase, more space on screen because of less UI. Bad news is app management requires connecting to a monitor because of the firefox extension panel issues. Annoying but not the worst issue to deal with. Once apps are installed they seem to work well so far
Glad you got it working and that it’s provided a performance bump!
Can you elaborate? Are you saying that the extension panel is hidden? If so, I had worked around this for brief adjustments by temporarily setting the screen resolution to 100% scaling.
I don’t remember having to do anything like that. Which folder did you duplicate? A new Firefox profile (created in firefox-esr -ProfileManager) is stored within $HOME/.mozilla/firefox/<profile_name>.
Update: a known limitation is that the firefox process appears to linger around after closing the application, and this can cause system unresponsiveness/crashes over time. I would like to test this by appending a kill clause to the .desktop file, perhaps similar to what @Emma did for the chatty application:
Until then, I’m working around it by periodically checking for and killing stale firefox processes with ps -ef | grep firefox.
Apologies, I should clarify that I was talking about the Firefox extension posted by maneth.
Can you elaborate? Are you saying that the extension panel is hidden? If so, I had worked around this for brief adjustments by temporarily setting the screen resolution to 100% scaling.
Haha, admittedly this is obvious but I didn’t think to try that - I will!
I don’t remember having to do anything like that.
I’m away from my L5 so I’m going by memory here but I believe the extension tries to download Firefox directly - but as there doesn’t seem to be an ARM64 version on the site it tells you to do the “advanced setup” where you have to download Firefox (or similar browser) and place it in the specified directory it requires. So what I did was literally duplicate the entire Firefox-esr application folder and move the copy to the “runtime” folder it tells you to use. Then I had to make a symlink from firefox-esr to “firefox” (I guess that’s what the extension is looking for) and fix some ownership permission issues to make it belong to the local user. After that it worked
Update : a known limitation is that the firefox process appears to linger around after closing the application
Ah you know what, my L5 did actually hang and become unresponsive after trying to unlock it last night but I thought it was unrelated. Looks like it may affect that plugin too. Nothing is ever easy, lol…
BTW: Did you manage to figure out any solutions / insights to this?
This issue also appears to be happening to me with the firefox PWA plugin. About every 24 hours I get a full system crash which requires a restart so definitely seems to be an issue with Firefox itself as far as I can tell.
Unfortunately not, but I admittedly haven’t spent much time looking into it. I’ll dig into it more this week. As a temporary workaround, I’ve been using the sledgehammer approach every once in a while after closing my firefox sessions… killall firefox-esr 2> dev/null
@JCS, Yeah, I’m doing something similar at the moment too. It seems to me that the same web app creates multiple processes over time, even if the app isn’t closed.
It’s a shame because performance-wise, firefox definitely runs web apps better than epiphany - minus the memory leaks of course.
If you do manage to make any progress on that front, please share!
I found a solution that I’ve managed to get working on desktop really nicely, but am one step away from getting to work on mobile (perhaps someone can help fill in the remaining steps).
On desktop, it works wonderfully, you create a profile for each app, and it colours the titlebar according to the website, you install only the addons necessary for that profile, and get a clean interface.
If it doesn’t automatically install, you may need to install the FUSE OverlayFS runtime; for the Librem 5 it needs this, but I didn’t need to for desktop
Step 3 is where I get stuck. I’ve tried modifying the path as follows since it is Firefox-ESR installed:
export FIREFOX_RUNTIME=/usr/lib/firefox-esr
sed -i -e “s|%RUNTIME-PATH%|$FIREFOX_RUNTIME|” $HOME/.config/systemd/user/firefoxpwa-runtime-overlayfs.service
But I get to the final step to install and enable the runtime, and I get the following response which I am stuck on so far:
Assertion failed on job for firefoxpwa-runtime-overlayfs.service.
Not sure if relevant, but could you check if there’s anything in journalctl logs (grep relevant terms), just to get more info to work with. And terminal systemctl status firefoxpwa-runtime-overlayfs.service if it works for you. In this case you could alse check you desktop logs if something there differs from L5’s regarding this.
AI suggested possibilities to try (based on only the error message):
Modify Service Dependencies: If the service is failing due to dependencies not being ready, you may need to modify the service file to ensure that it waits for the necessary directories to be mounted. You can edit the service file (usually located in /etc/systemd/system/) and add dependencies using After= and Requires= directives. For example:
Use Automount Options: If the directories required for OverlayFS are not ready at boot time, consider using the x-systemd.automount option in your /etc/fstab file. This allows the filesystem to be mounted on first access rather than at boot time, which can help avoid failures if the directories are not yet populated (source)
