Open Bug 1278719 (flatpak) Opened 8 years ago Updated 1 year ago

[meta] Use Flatpak framework to distribute Firefox for Linux users

Categories

(Firefox Build System :: Third Party Packaging, enhancement)

Product:
Firefox Build System
Component:
Third Party Packaging
Platform:
All
Linux
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: diazbastian, Unassigned)

References

(Depends on 61 open bugs,
URL
)

Details

(Keywords: meta)

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:46.0) Gecko/20100101 Firefox/46.0 Build ID: 20160512103250 Actual results: Firefox updates depend on each Linux distribution maintainers, which makes its slow deployment. Considering the importance of security updates in a web browser, this system is inefficient. Moreover, the classic tarballs are unfriendly to the end user. In the Mozilla blog, announced to use Snap to distribute Firefox on Ubuntu https://blog.mozilla.org/futurereleases/2016/04/21/firefox-default-browser-for-linux-users-ubuntu-new-snap-format-coming-soon/ Snap is package format with good intentions and has good features like sandboxing or direct update from the author, however, is a niche technology and is very hard to use a Snap application outside Ubuntu, even in previous Ubuntu versions or other Debian based systems. Expected results: It would be great to distribute Firefos as a Flatpak package (aka xdg-app) for Linux users. Flatpak (http://flatpak.org/) is a nice framework to distribute applications on Linux standalone, safely and independently of the linux distro. The Document Foundation, distribute LibreOffice as a flatpak package (https://www.libreoffice.org/download/flatpak/). Flatpak is still in active development, but it is very promising features. Currently you can use Flatpak in several distributions very easily, including Ubuntu. In addition existing graphical tools that support easy installation Flatpak applications.
Severity: normal → enhancement
Considering the fact that this is an enhancement, I will assigned a component to this issue in order to involve the development team and get an opinion on this.
Component: Untriaged → Build Config
(In reply to Cosmin Muntean [:CosminMCG] from comment #1) > Considering the fact that this is an enhancement, I will assigned a > component to this issue in order to involve the development team and get an > opinion on this. Thank you very much
I've created a PoC of the manifest at https://github.com/vrutkovs/firefox-flatpak
Given that Snap is now universal to Linux, is this still the correct approach?
(In reply to Paul [pwd] from comment #4) > Given that Snap is now universal to Linux, is this still the correct > approach? I don't think you're right. Snap is still Ubuntu only but flatpack is distro independent. See https://www.reddit.com/r/linux/comments/4kxbqp/appimage_snaps_flatpak_pros_and_cons_comparison/d3j3vv4 for details.
See http://lwn.net/Articles/691309/ That doesn't change there's no indication which one will win on the long run.
(In reply to Mike Hommey [:glandium] from comment #6) > See http://lwn.net/Articles/691309/ > > That doesn't change there's no indication which one will win on the long run. Sure. My point is that Snap is Ubuntu only now and other distros needs to use something else. OTOH flatpack can be distributed on all distros include Ubuntu.
The point is Snap *is* going to be available on all the major distros, according to that lwn article.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Unspecified → Linux
Hardware: Unspecified → All
Version: 46 Branch → Trunk
(In reply to Mike Hommey [:glandium] from comment #8) > The point is Snap *is* going to be available on all the major distros, > according to that lwn article. I'm not aware of any effort to get Snapy on Fedora by default (but it's possible to install it from third-party repo) and I don't expect Fedora will adopt that. AFAIK there's one big problem here - you can't create third party Snapy repo which is independent on Canonical - all Snappy packages has to be distributed from there. Correct me if I'm wrong.
(In reply to Martin Stránský from comment #9) > (In reply to Mike Hommey [:glandium] from comment #8) > > The point is Snap *is* going to be available on all the major distros, > > according to that lwn article. > > I'm not aware of any effort to get Snapy on Fedora by default (but it's > possible to install it from third-party repo) and I don't expect Fedora will > adopt that. > > AFAIK there's one big problem here - you can't create third party Snapy repo > which is independent on Canonical - all Snappy packages has to be > distributed from there. Correct me if I'm wrong. It's worth noting that all of the news today states that Fedora will support snaps natively http://snapcraft.io/ http://arstechnica.com/information-technology/2016/06/goodbye-apt-and-yum-ubuntus-snap-apps-are-coming-to-distros-everywhere/ http://betanews.com/2016/06/14/ubuntu-snap-packages-linux-distros-fedora-arch-mint-opensuse/ https://insights.ubuntu.com/2016/06/14/universal-snap-packages-launch-on-multiple-linux-distros/
(In reply to Paul [pwd] from comment #10) [...] > It's worth noting that all of the news today states that Fedora will support > snaps natively > http://snapcraft.io/ > http://arstechnica.com/information-technology/2016/06/goodbye-apt-and-yum- > ubuntus-snap-apps-are-coming-to-distros-everywhere/ > http://betanews.com/2016/06/14/ubuntu-snap-packages-linux-distros-fedora- > arch-mint-opensuse/ > https://insights.ubuntu.com/2016/06/14/universal-snap-packages-launch-on- > multiple-linux-distros/ That articles comes from Ubuntu folks and are more wish than reality.
(In reply to Paul [pwd] from comment #10) > (In reply to Martin Stránský from comment #9) > > (In reply to Mike Hommey [:glandium] from comment #8) > > > The point is Snap *is* going to be available on all the major distros, > > > according to that lwn article. > > > > I'm not aware of any effort to get Snapy on Fedora by default (but it's > > possible to install it from third-party repo) and I don't expect Fedora will > > adopt that. > > > > AFAIK there's one big problem here - you can't create third party Snapy repo > > which is independent on Canonical - all Snappy packages has to be > > distributed from there. Correct me if I'm wrong. > > It's worth noting that all of the news today states that Fedora will support > snaps natively > http://snapcraft.io/ > http://arstechnica.com/information-technology/2016/06/goodbye-apt-and-yum- > ubuntus-snap-apps-are-coming-to-distros-everywhere/ > http://betanews.com/2016/06/14/ubuntu-snap-packages-linux-distros-fedora- > arch-mint-opensuse/ > https://insights.ubuntu.com/2016/06/14/universal-snap-packages-launch-on- > multiple-linux-distros/ I think Canonical is using the power of marketing, because use a Copr repository created by an employee of Canonical is far from being a work with the community and provide snap natively. You may find Flatpak in the official repositories of Arch and not in a AUR repository as Snap (Copr and AUR are repositories that can be created by any user and are not safe per se).
(In reply to Martin Stránský from comment #9) > (In reply to Mike Hommey [:glandium] from comment #8) > > The point is Snap *is* going to be available on all the major distros, > > according to that lwn article. > > I'm not aware of any effort to get Snapy on Fedora by default (but it's > possible to install it from third-party repo) and I don't expect Fedora will > adopt that. > > AFAIK there's one big problem here - you can't create third party Snapy repo > which is independent on Canonical - all Snappy packages has to be > distributed from there. Correct me if I'm wrong. What you mentioned is correct. It's a big problem because Canonical wants to create a centralized repository and distribute applications in their store, therefore, rather than creating an application distribution system for Linux, means something like "You can install Ubuntu applications on any distribution" and maintain the control of then. The operation will be similar to the Google Play Store, so all Snap with external repositories, they will be marked as unsafe by default. I think that's not the agnostic distribution system is expected. I prefer to download an application directly from the author's website and this without intermediaries (Canonical servers) can make any upstrean changes. Besides the size of the Snap packages they are crazy and as such can compare and unofficial Snap package (~1GB) and official Flatpak package (~160MB) of LibreOffice. As an additional note, the Flatpak runtimes are additional weight, but can be used by multiple applications.
Also Flatpak seems more secure. They give access to the app only when needed. If a crazy user wants to open ~/.ssh in Firefox, the user will press Ctrl+O, Firefox will ask GTK to open the file, the user will browse and select the file, then GTK will offer the file as a bind mount to Firefox. If an evil addon wants to do the same, it cannot. It needs user interaction for this. Basically the GTK file open/file save dialog guards the user's file system. I really like Flatpak's security model more than any other GNU/Linux way of distributing binaries.
FIY we've setup experimental unofficial Firefox Developer Edition flatpak repository there: https://firefox-flatpak.mojefedora.cz/ with some installation instructions. There are build scripts available on github: https://github.com/xhorak/firefox-devedition-flatpak Currently our package grants access to whole filesystem as long as it is experimental stuff.
https://bugzilla.mozilla.org/show_bug.cgi?id=1332404 - may be needed for bringing plugins for flatpaked Firefox
Depends on: 1351723
Depends on: 1332404
Depends on: 1352416
Depends on: 1396733
I think https://kamikazow.wordpress.com/2017/02/09/adoption-of-flatpak-vs-snap/ is worth looking. I hope to see this bug fixed, especially thinking about developer edition
Has anyone from Mozilla commented on whether this could be worked on or what is stopping them? Would be great to have the same stable / beta / nightly channels available on linux as other platforms through flatpak
Flags: needinfo?(mh+mozilla)
Flags: needinfo?(mh+mozilla) → needinfo?(catlee)
Unfortunately we're not going to be able to get to this in Q4.
Flags: needinfo?(catlee)
This is something that we have looked at (you can see by the dependent bugs), but we haven't got enough traction internally to decide exactly what the next steps are. Based on my understanding of things, we need some Firefox specific patches in order to support special app paths inside the Flatpak and that would require a Flatpak unique build of Firefox. I'd like to know if there is anything we can do to use a standard Firefox in a Flatpak or if we have to have the build changes referenced in the other bugs? I honestly don't know enough about how Flatpaks work. This is definitely something we would look to a community member to help drive.
The fedora people are shipping flatpaks of an experimental (aiui) wayland-enabled firefox, surely they can say what's needed.
Flags: needinfo?(jhorak)
Fedora provides flatpak Firefox at https://firefox-flatpak.mojefedora.cz/ for: FirefoxNightly - Firefox Nighly FirefoxDevEdition - Firefox Developer Edition FirefoxNightlyWayland - experimental Wayland port FirefoxNightlyCSD - experimental CSD port There's also official flatpak "Store" at https://flathub.org/ with registered flatpaked apps. We (Fedora folks) can surely pack and distribute Firefox at official flatpak store but we feel it would be better if the packages will be under direct Mozilla control. We're keen to help with any technical issues, provide the flatpak file etc.
What are the actual code changes to Firefox needed to make a Flatpak work?
AFAIK No code changes. See the scripts used by Fedora to build flatpak from various Mozilla releases: https://github.com/xhorak/firefox-devedition-flatpak 1) You can flatpak existing Mozilla nightly binary builds by: https://github.com/xhorak/firefox-devedition-flatpak/tree/master/org.mozilla.FirefoxUpstreamBinary 2) or do the whole build: https://github.com/xhorak/firefox-devedition-flatpak/tree/master/org.mozilla.FirefoxNightly I think the easiest start is to just place existing Nightly binary generated by Mozilla to flatpak shell. The examples at (1) may be outdated as we don't use that now but if you're interested we can surely update them for production use.
Depends on: 1411579
Flags: needinfo?(jhorak)
I'm going to fill some bugs what is not working ATM.
Depends on: 1411589
Alias: flatpak
Keywords: meta
I am no expert with flatpa but on Debian, the following worked for me: sudo apt-get install flatpak sudo flatpak install --from https://firefox-flatpak.mojefedora.cz/org.mozilla.FirefoxNightly.flatpakref flatpak run org.mozilla.FirefoxNightly
I've a working sample: https://gitlab.com/stevendobay/flatpak-plus/tree/master/org.mozilla.Firefox It only works for x86_64 but everything seems to work with it(I'm using it for 2 days). It only gets permission to open $XDG_DOWNLOADS.
Depends on: 1071061
Depends on: 1441922
I've just updated scripts to build from upstream binaries: https://github.com/xhorak/firefox-devedition-flatpak/tree/master/org.mozilla.FirefoxUpstreamBinary There's a README how to do it. It downloads langpacks and puts them in distribution directory to make langpacks working (with inspiration in Firefox for snap: https://reviewboard.mozilla.org/r/79290/diff/2#index_header ).
Component: Build Config → General
Product: Firefox → Firefox Build System
We're actively working on a Flatpak. It's in this bug https://bugzilla.mozilla.org/show_bug.cgi?id=1441922
Depends on: 1491993
Summary: Use Flatpak framework to distribute Firefox for Linux users → [meta] Use Flatpak framework to distribute Firefox for Linux users
Feedback: I installed Firefox Nightly from the Flatpak repo, because of bug #1514730. I force-enabled hardware acceleration and enabled Webrender. Also, I added DRI_PRIME=1 to the launch command. 1. Scrolling doesn't lag currently. I'll keep observing. 2. There's few lag in other places, but it doesn't make my experience terrible like the scrolling lag. Unfortunately, the Flatpak (or maybe all Nightly) doesn't support send technical and interaction data to Mozilla to help development.
Depends on: 1515136

I can see there has been some discussion about Flatpak and Snap here.

I wanted to point out that my colleague Valentin spent some time last month demonstrating a build of a single application targeting both snap and flatpak, this is interesting as it allows one to reuse much of the same build instructions, reducing the maintenance burden of supporting both distribution methods.

Coincidentally, he used Firefox as the application to build for this experiment. As it is a complicated enough build, Firefox was a good choice for the demo.

I thought it might be helpful to link his work here:

Blog post: https://valentindavid.com/posts/2019-03-27-freedesktop-sdk-snap/
Gitlab repo: https://gitlab.com/valentindavid/firefox-buildstream/

Depends on: 1618094

I tried beta build from flathub and noticed that wayland cannot be enabled, even with flatpak override, should i file a bug?

Depends on: 1622504
Depends on: 1622510

@Seqularise You likely forgot to add the --user, it seems this flatpak is installed to the local user only. I got it working via "flatpak override --env=GDK_BACKEND=wayland org.mozilla.firefox --user"

Depends on: 1622425

Overriding GDK_BACKEND=wayland breaks Firefox with the following message:

(firefox:2): Gtk-WARNING **: cannot open display: :99.0

The flatpak build requires --socket=wayland to be set for Wayland support to be enabled. Run

flatpak override [--user] --socket=wayland org.mozilla.firefox

to fix that. Should probably be added to finish-args.

Depends on: 1627831
Depends on: 1627834
Depends on: 1628098
Depends on: 1628428
Depends on: 1628471
No longer depends on: 1628471

My flatpak version of firefox 75 has User Namespaces set to false, is this a bug?

(In reply to monterro from comment #41)

My flatpak version of firefox 75 has User Namespaces set to false, is this a bug?

Flatpak blocks apps from using User Namespaces so this is expected.

I just tried out the flathub flatpak for Firefox 75.0 and noticed these things:

  1. The only filesystem permission is xdg-download. The Fedora flatpak had several other locations enabled including ~/.mozilla. Is the flathub flatpak storing the user profile inside of the flatpak?
  2. I tried "flatpak run --filesystem=host org.mozilla.Firefox" so that the flatpak could see my profile. I got the warning about running an older version of Firefox even though the latest version of Firefox I have used that profile with is the rpm version of Firefox 75.0. What is going on there? Can I use my existing profile with the flatpak version of Firefox?

(In reply to wsha.code from comment #43)

I just tried out the flathub flatpak for Firefox 75.0 and noticed these things:

  1. The only filesystem permission is xdg-download. The Fedora flatpak had several other locations enabled including ~/.mozilla. Is the flathub flatpak storing the user profile inside of the flatpak?

User profile is stored in ~/.var/app/org.mozilla.firefox/.mozilla . It's not shared with profiles created from other firefox packages.

  1. I tried "flatpak run --filesystem=host org.mozilla.Firefox" so that the flatpak could see my profile. I got the warning about running an older version of Firefox even though the latest version of Firefox I have used that profile with is the rpm version of Firefox 75.0. What is going on there? Can I use my existing profile with the flatpak version of Firefox?

Just copy ~/.mozilla to ~/.var/app/org.mozilla.firefox/.mozilla

Depends on: 1629378

What is the recommended way to provide feedback on the released Flatpak? Do we open new bugs, or is it sufficient to note things here?

After attempting to use this for the last few days, I've noted the following:

  • Notifications don't work. I need to run flatpak override --user org.mozilla.firefox --talk-name=org.freedesktop.Notifications.
  • The SpeechSynthesis API doesn't work in the Flatpak, but works fine on my desktop. Guessing another dependency is needed in the Flatpak?

Thanks.

Just copy ~/.mozilla to ~/.var/app/org.mozilla.firefox/.mozilla

Thanks, I hadn't realized apps stored data in ~/.var. I tried copying ~/.mozilla as suggested, but I still get the dialog about using an older version of Firefox. Both "firefox --version" and "flatpak run org.mozilla.firefox --version" give me "Firefox 75.0". Any idea why the flatpak doesn't like in profile?

Please open a new bug for any issues you find with the Flatpak. You can find bugs that have already been reported here:

https://bugzilla.mozilla.org/buglist.cgi?product=Release%20Engineering&component=Release%20Automation%3A%20Flatpak&resolution=---

Restrict Comments: true
Depends on: 1630203
Depends on: 1630922
Depends on: 1631400
Depends on: 1633341
Depends on: 1630770
Depends on: 1638150
Depends on: 1639609
Depends on: 1645767
Depends on: 1648024
Depends on: 1646462
Depends on: 1650640
Depends on: 1649672
Depends on: 1666084
Depends on: 1667038
Depends on: 1675312
Depends on: 1662552
No longer depends on: 1678345

On ChromeOS, the Downloads directory does not appear to function correctly. I am not sure if this is a problem with the $xdg_download setting or something inherent in ChromeOS. Running with --filesystem=home solves the problem, and makes firefox operate much like it does when installed natively (writing config opts under ~/.mozilla etc.)

I tried adding --filesystem=~/Downloads, and was able to navigate to the correct Downloads directory, however subsequent downloads defaulted to the internal, inaccessible download directory and downloaded items were silently dropped.

(I used Flatseal to make these changes more permanent on Linux under ChromeOS)

Depends on: 1697086
Depends on: 1703335
Depends on: 1714318
Depends on: 1712555
Depends on: 1722221
Depends on: 1724900
Depends on: 1726211
No longer depends on: 1724900
No longer depends on: 1726211
Depends on: 1726251
Depends on: 1726530
Depends on: 1726320
Depends on: 1631193
Depends on: 1729464
Depends on: 1734073
Depends on: 1741889
No longer depends on: 1741889
Depends on: 1744410
Depends on: 1755180
No longer depends on: 1688720
Depends on: 1688720
Depends on: 1751322
Depends on: 1759840
Depends on: 1762854
Depends on: 1764700
Depends on: 1770636
Depends on: 1769958
Depends on: 1765089
Component: General → Third Party Packaging
Depends on: 1786132

https://evertpot.com/firefox-ubuntu-snap/ The post was about Snap (some of the issues are present in Flatpak too I assume), but there's a comment saying the Flatpak crash reporting is broken. No more details, but that's one of the things that wouldn't hurt to check once too many...

Depends on: 1790766
Severity: normal → S3
Depends on: 1805440
Depends on: 1803066
Depends on: 1807468
Depends on: 1802802
No longer depends on: 1802802
Depends on: 1808174
Depends on: 1808754
Depends on: 1814897
Depends on: 1817081
Depends on: 1827410
Depends on: 1670333
Depends on: 1828345
No longer depends on: 1828161
No longer depends on: 1828345
Depends on: 1832319
Depends on: 1702618
Depends on: 1835752
Depends on: 1836158
Depends on: 1837144
Depends on: 1849397
Depends on: 1850269
Depends on: 1774062
No longer depends on: 1850269
You need to log in before you can comment on or make changes to this bug.