Which Gecko version will be available in the next SailfishOS Update 4.4?

Does Anybody know if GeckoEsr 78 will be next, or 91?

5 Likes

There has been an ESR78 branch on Github for ages, while I have seen no 91 branch. If gecko gets upgraded, I’d expect 78 for now.

7 Likes

Thank you. But why can’t Jolla just skip esr 78 and go straight to esr91?

And why did Jolla use geckoESR instead the normal gecko? That they get behind with the update at all?

It´s a pitty that Jolla don´t update the Browser engine over the store independent of the os.

1 Like

Upgrading the browser engine takes some effort. You need to verify which of the overrides Jolla applies, are still necessary or need fixing. It needs to interact with the OS properly, which includes URL changes, embedded in a webview, sandboxing, the UI, etc. There is simply a lot to test and fix every time and the browser is integrated into the OS as a component, that other applications can reuse, so it can’t just be a package on the store. Pretty much every time you think “why can’t X just”, the answer often is that it is more complex than expected or it needs more resources than are available for it. :wink:

I suggest you look at the 78 branch on github and see, what work was done after bumbing the version to 78. And then you’ll also understand, why Jolla uses the Extended Support version instead of always the latest short term support of Gecko.

14 Likes

In addition to the great answer from @KuroNeko , I may add that the gecko-dev repository contains at the moment a upgrade-4.4.0 branch. Jolla is often using such naming to have a branch to backport fixes from master for a version that is already in release testing state. The spec file in this branch is : https://github.com/sailfishos/gecko-dev/blob/upgrade-4.4.0/rpm/xulrunner-qt5.spec where we can see that version is 78.15.1

5 Likes

Nice. Would love to find a test build somewhere.

thanks for your deklarations @KuroNeko & @dcaliste. I thought it was complex, needs many recourse and time. But now i understand it very very complex. Thank you again.

2 Likes

I will also add that there’s nothing wrong with ESR long-term support branch of Firefox in general.

Even more, I use it on all my computers, since updating it never breaks customizations in cssChrome.
If you do have them too, I suggest you to use ESR.
That way they brake only once a year, when ESR version jumps to new “main” version (e.g. 68 > 78 > 91).

thanks, I know the advantage of the Esr, that Mozilla updated it once a year with new features but with security fixes as soon as possible. It’s a pitty that Jolla have not enough recourses to do it at the same way.