[RPM Request] Firefox 78, mobile build

Applications
#1

Part of the PinePhone comunity have made a mobile-friendly and distro-agnostic build config for firefox.

Would some community dev with more free time than me (and perhaps access to pre-release SFOS 3.4.0 -devel files) like to try if they could compile an RPM for SFOS ?

It won’t be as well integrated as a native Sailfish QML app, but it’s still better than relying on the Android layer for Firefox needs.

28 Likes
#2

Would be lovely indeed.

2 Likes
#3

AFAIR firefox needs some more recent software (gcc, wayland).

But maybe flatpak support is possible?

3 Likes
#4

Firefox for Android 78 (aka Fenix, aka Daylight) requires Android 5+ (so won’t run under Alien on my Jolla C). I don’t know why not - e.g. whether it just simplifies maintaining it.

My main interest is getting it to run arbitrary (i.e. my own) addons. Unapproved addons in the profile are not installed. It looks like it has a whitelist. Any info in that would be appreciated.

They’ve recently sort-of-comitted to allow side-loaded addons in nightly builds: https://discourse.mozilla.org/t/add-on-support-in-new-firefox-for-android/53488

#5

@DaveRo : the present thread is about using a mobile-friendly optimisation of the full-blown GNU/Linux desktop version of Firefox.
(Work that has been done as part of the Pine Phone community - several of the GNU/Linux distro available on it don’t even have Android App support - i.e. Anbox - to begin with)
This has nothing to do with the Android App version of Firefox.

This could be a solution in your case, given that it doesn’t rely on any Android support at all, and the desktop version’s Web Extension system is stable and mature enough to not rely on any whitelist.

But as pointed out by @michfu the main issue is that this application relies on much more recent version of gcc, wayland, etc. than what is currently available in Sailfish OS. Jolla is aware that it is seriously lagging behind on that point and are working on it. So maybe in some future version of Sailfish, this would be fixed too. (In the maintime, packaging local dependencies as suggested above seems a good possibility, too).

With regards to your question:

  • the android API has substantially changed between 4.2 KitKat and 5.0 Lollipop. I suspect that Mozilla want to alleviate the extra burden of maintaining all the alternative fallbacks. (But would be losing in the process some users with older phones like you). As it is an opensource project, maybe some project will pop-up maintaining an alternate fork for older devices. (see how that hapenned back when mozilla dropped Firefox support fro Windows 95)
  • the engine in Firefox 78 (GeckoView) has been quite overhauled and it hasn’t been extensively tested yet on Android: the whitelist is probably a measure to restrict to known good versions of addons that do not crash it. I am sure that there’s some setting in about:config that could be used to force non-whitelisted add-ons, I just don’t bothered because all those I need the most miraculously happen to all have been whitelisted.
    They have more information on their blog. Over time more will be added, and eventually only the blacklist of known evil extensions will be maintained.
3 Likes
#6

It would be nice to have up to date browser like Firefox 78 for Android but I think we can start to think about SailfishOS as a good browser.
In 3.4 we will have gecko 52 and they startred to work on gecko 60 based browser (so first version with Quantum).

7 Likes
#7

@DrYak Thanks - and apologies: I hadn’t realised it was the desktop build.

(I’m investigating the Fenix whitelisting - but that’s OT here.)

#8

Its not only the engine. Its many more stuff that firefox has.

#9

Was hoping they’d get FF 63+ in by now, since it’s the first version with Web Components enabled by default.

1 Like
#10

We have gecko 52 now indeed in 3.4.0.22.

When can we expect gecko 60? We know there are working on it: https://git.sailfishos.org/mer-core/gecko-dev/tree/sailfishos-esr60-wip

Will this be in a point release, eg 3.4.1? Still in 2020 I hope.

1 Like
#11

We have Gecko 60 now in 4.0.1.

Unfortunately, web components still don’t render, so still wondering, if there’s an early RPM build channel I could hop on to get ESR68 build or whatever the team is currently working on for next release?

1 Like