Would it be possible to backport FF 52 changes to TFF if it targeted Leopard?

[featherwhisker]

Would using 10.5 as a minimum make it possible to backport FF52 and possibly boost performance? I've noticed that most software made past 2008 only supported Leopard on PPC and a lot of software backporting that happens stops at 10.5 intel or 10.6 because Tiger is so outdated. Would using Leopard Xcode and APIs fix that? I don't know much about Xcode and Mac software development so correct me if I'm wrong

 

[joevt]

What are FF52 and TFF?

 

[TheShortTimer]

What are FF52 and TFF?

Firefox 52 and Ten Four Fox, I suspect.

Edit: yep they're listed in the subject tags.

 

[AdamBuker]

I'm not a programmer so take what I say with a huge dose of salt. My understanding is that the problem with backporting more modern browsers to PPC OS X is that not only does the program itself need to be backported, but so do all the libraries and other components upon which the browser depends. Theoretically it could be done, but there is so much work involved that I understand it not to be worthwhile to most programmers.

 

[alex_free]

I think the real problem is the absolute tragedy that is the 'oxidiztion' of FireFox. Introducing rust kind of killed off anything new getting backported in a way IMO. That is an issue with the code base (as a C snob). If it was all written in C still, it would be more possible.

 

[barracuda156]

I'm not a programmer so take what I say with a huge dose of salt. My understanding is that the problem with backporting more modern browsers to PPC OS X is that not only does the program itself need to be backported, but so do all the libraries and other components upon which the browser depends. Theoretically it could be done, but there is so much work involved that I understand it not to be worthwhile to most programmers.

Pretty much everything of library dependencies build and work in either latest or very recent versions, so that is not an issue.

What makes it impossible (in practical terms) to fix the current FF is their ill-thought, marketing-driven choice of requiring rust.

P. S. Looking at the Palemoon page, I see nothing about rust being required though. If it is not indeed, then this is a feasible option. Likely with GTK backend: I expect Cocoa to be broken there.
Somewhat easier perhaps would be to fix White Star or Arctic Fox: both build, neither works at the moment.

 

[featherwhisker]

I think the real problem is the absolute tragedy that is the 'oxidiztion' of FireFox. Introducing rust kind of killed off anything new getting backported in a way IMO. That is an issue with the code base (as a C snob). If it was all written in C still, it would be more possible.

FF52 was the last version that included no rust. Only concern is that it has a newer minimum OS X requirement than FF 45 (10.9 vs 10.6)

That was why I was asking if it would be possible to backport it to 10.5 if we drop 10.4 compatibility. 10.4 is like Windows XP when it comes to API support while 10.5 is like Vista and a lot of things can be easily backported from 7 and 8.1 to Vista.

Palemoon itself was based on FF52 for 28+ too so if we backport FF52 we could backport all of the changes Goanna makes to get a semi-modern render/layout engine

 

[barracuda156]

FF52 was the last version that included no rust. Only concern is that it has a newer minimum OS X requirement than FF 45 (10.9 vs 10.6)

That was why I was asking if it would be possible to backport it to 10.5 if we drop 10.4 compatibility.

10.9 vs 10.6 is a huge jump. It is quite unlikely Cocoa stuff will build or, perhaps, is even fixable.

What may work is building it with GTK backend instead – in that case the only constraint for updates is a requirement to be rust-free. I.e. how it is built on other Unix-like systems.

GTK2–3 work fine on old macOS, and GTK4 (which is perhaps irrelevant for these, still rather old, versions of FF) works with minor issues. As long as it is not beyond GTK3, experience should be rather smooth.

 

[Jazzzny]

Firefox 52's (and Firefox 53's, which is what InterWeb is based on) Cocoa backend is pretty much 95% compatible with 10.6 - its just a few changes that need to be reverted.

I don't believe that Firefox's GTK backend will ever be worth the effort to get working on OS X - there is just too much platform-specific code that is hardcoded into the Cocoa backend.

In terms of Rust, Firefox versions up to 55 can be built without Rust, so that shouldn't be an issue.

The ideal way moving forwards is to get UXP (Based on Firefox 52, backbone for Pale Moon, White Star, and Basilisk) working properly on PowerPC. Once that is done, PPC machines will finally have access to a modern web browsing engine, as UXP is actively maintained in all areas (CSS, JavaScript, and other specifications).

 

[barracuda156]

The ideal way moving forwards is to get UXP (Based on Firefox 52, backbone for Pale Moon, White Star, and Basilisk) working properly on PowerPC. Once that is done, PPC machines will finally have access to a modern web browsing engine, as UXP is actively maintained in all areas (CSS, JavaScript, and other specifications).

White Star builds, both with Cocoa and GTK, but neither version actually works at the moment LOL

 

[Jazzzny]

White Star builds, both with Cocoa and GTK, but neither version actually works at the moment LOL

I've been following along with the White Star progression for a while now, and I believe dbsoft is pretty close to getting things working properly. As Firefox renders the browser chrome as a "pseudo webpage" (chrome://browser/content/browser.xul), if the browser page loads then to my knowledge the chrome itself shouldn't be too far off.

 

[thewireless]

@barracuda156, would targeting 10.6 (PPC) instead of 10.5 make any difference? Not for TFF, but for browsers like Arctic Fox and the others available on 10.6 Intel and PPC Linux.

 

[barracuda156]

@barracuda156, would targeting 10.6 (PPC) instead of 10.5 make any difference? Not for TFF, but for browsers like Arctic Fox and the others available on 10.6 Intel and PPC Linux.

If you mean 10a190 (likely you do), then it depends. While admittedly not as polished as 10.5.8, 10a190 does have newer SDK features, which make difference with some ports (difference not abstract, but very obvious: a port which builds and works in 10a190 may not build at all on 10.5.8, and I have a specific example in mind). Having said that, 10a190 has another problem: assumptions made for 10.6 may not hold, and that also can cause breakages. Easy example is Qt4: while I was able to build it against 10a190 SDK (as 10.6), it did not work correctly, so I dropped the target to 10.5, which, while suboptimal, at least works (in MacPorts qt4-mac builds for 10.5 target on 10.6 Rosetta, officially, and 10.6 ppc, unofficially).

I do not know at the moment if it gonna be better or worse with Pale Moon forks. I can say for sure it is less trivial, since it will require more patches just to get the build completed. But it is possible that with those patches 10a190 will work, while 10.5.8 gonna fail regardless.

Now, I believe, without for or counter evidence presently, that 10.6.8 must improve things substantially, but there are two caveats:
– until/unless we fix DNS/DHCP in 10.6.8, at least browser is rather meaningless there;
– it may (or may not) depend on how well forward-porting of OpenGL and related frameworks fits with third-party software: it is conceivable that we get additional problems due to that, but there is no perfect solution here, at least for now.