Open Bug 1352416 Opened 7 years ago Updated 2 years ago

Provide a way for Flatpaks to use /app dir for system extensions

Categories

(Core :: XPCOM, enhancement, P3)

52 Branch
enhancement

Tracking

()

People

(Reporter: mkaply, Unassigned)

References

(Blocks 1 open bug)

Details

Currently we hardcode the system extension location on Linux:

http://searchfox.org/mozilla-central/source/toolkit/xre/nsXREDirProvider.cpp#463

Flatpaks do not have access to this directory.

From the Flatpak folks:

Well, I've hit hardcoded path problem. The /usr/share/mozilla/extensions path cannot be changed:
http://searchfox.org/mozilla-central/source/toolkit/xre/nsXREDirProvider.cpp#465
Flatpak does not allow to write to /usr/whatever during install, only to /app/usr/whatever (ie. using prefix).
So we can't put langpack.xpi to the location from where it could be loaded.
What is flatpak and why should it support system extensions?
Flags: needinfo?(mozilla)
Flatpak is a new packaging format for application distribution on Linux:

http://flatpak.org/

We are looking at the possiblity of creating an official Firefox flatpak.

Currently the various Linux distros ship multilocale Firefox (not fully supported, but good enough for what they are doing). They do that by shipping the various langpacks.

They would like to bundle the langpacks as part of the Flatpak, but to do that it would have to look for the langpacks inside of the Flatpak bundle, not in the operating system.
Flags: needinfo?(mozilla)
Priority: -- → P3
We can do better than shipping all langpacks in one giant Flatpak, by leveraging the Locale extension support in Flatpak. I've sketched out how this might work in https://bugzilla.mozilla.org/show_bug.cgi?id=1441922#c13 but am happy to provide more details or patches if you have a WIP I can look at.

However: in either case, the Firefox flatpak can only provide files in /app, as /usr is controlled by the runtime/platform. So we'd either need Firefox to figure it was running under a Flatpak, and change the prefix, or we'd need a way to influence the search path for the langpacks which can be activated by the Flatpak at runtime, such as an env var or command line option.

You can detect running under Flatpak (and indeed, understand a lot about the sandboxing, build configuration, etc) using the /.flatpak-info file which is added into the sandbox by Flatpak at runtime. See https://gitlab.gnome.org/GNOME/glib/blob/master/gio/gportalsupport.c for example, which Glib uses to decide whether certain IO operations (files, notifications, app launches, etc) should be done via portals (D-Bus APIs provided by the host system from outside the sandbox).
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.