Jump to content

My Browser Builds (Part 4)


Recommended Posts

SeaMonkey's WebComponents support is improving - GitHub is beginning to work again under it, so that's something. (it runs on a highly modified FF56 base with security backports from the latest Firefox ESR)

Also, for those who like memes, one of its developers (tomman) was the creator of the infamous CrazyBus tech demo for the Mega Drive back in 2004.

http://helmet.kafuka.org/bboard/thread.php?pid=7385#7385

(link also contains a fixed version of Flashblock for SeaMonkey 2.53.x)

Wondering if the improved support and the active browser development (worth keeping an eye on, perhaps also worth helping with the upstream too btw) could potentially result in an XP backport? If so, I'd be more than happy to look into getting it featured on the "contributed builds" page for SeaMonkey itself. Or perhaps talk to them directly about that... they're not particularly a hostile bunch unlike PM, they were screwed over by Mozilla harder than anyone really, having had their infrastructure pretty much stripped away from them around the time Firefox decided to go super-woke with its public relations.

Edited by derpo
Link to comment
Share on other sites


1 hour ago, derpo said:

SeaMonkey's WebComponents support
...
(it runs on a highly modified FF56 base, with security backports from the latest Firefox ESR)

... You're probably mixing it up with WaterFox Classic :dubbio:, which is indeed based on Fx56 ...
SM 2.53.x branch is forked from a Firefox ESR 60.x code snapshot, specifically SM versions > 2.53.4 are based on FxESR 60.8 ...

https://en.wikipedia.org/wiki/SeaMonkey

1 hour ago, derpo said:

(worth keeping an eye on, perhaps also worth helping with the upstream too btw) could potentially result in an XP backport?

Feodor (a one-person "act") has managed to port FxESR 68 to WinXP/WinVista via his MyPal 68 project, though that involved using a custom, XP-compatible, version of the Rust coding language ... If the SM project are to take a similar route, then backporting SM 2.53.x (FxESR 60.x-based) to WinXP/Vista doesn't "sound" unfeasible... But I seriously doubt they'll be interested ;) ...

Link to comment
Share on other sites

Thanks to soggi and RoyTam1 for their help with
Palefill-1.26 !
Both Palefill-1.26 by Martok and the modified version by RoyTam1
now work as intended with the latest versions  (2023-01-28) of NM28 and St52.

Edited by anton12
Link to comment
Share on other sites

I'm not particularly up-to-date with all the extension updates. I'm still using Polyfill 1.2.19.3 from https://github.com/JustOff/github-wc-polyfill and Github for instance is still functioning fine as far as I can tell. Would it be better to start using https://o.rthost.win/boc-uxp/palefill-1.26.xpi? What are the main differences?

Link to comment
Share on other sites

@Reino Please read (and follow contained GH links) below GH comment:

https://github.com/JustOff/github-wc-polyfill/issues/71#issuecomment-1403998251

In short, the first extension has now become an abandonware; its last maintainer recommends migration to the second, which has a "broader" application (not limited to GH/GL) :) ...

Link to comment
Share on other sites

6 hours ago, Reino said:

I'm not particularly up-to-date with all the extension updates. I'm still using Polyfill 1.2.19.3 from https://github.com/JustOff/github-wc-polyfill and Github for instance is still functioning fine as far as I can tell. Would it be better to start using https://o.rthost.win/boc-uxp/palefill-1.26.xpi? What are the main differences?

In a Nutshell:
github-wc-polyfill obviously is just for GitHub and GitLab - Palefill is potentially for all websites.

So, yes it would be better to start using Palefill!

kind regards
soggi

Edited by soggi
Link to comment
Share on other sites

2 hours ago, VistaLover said:

Feodor (a one-person "act") has managed to port FxESR 68 to WinXP/WinVista via his MyPal 68 project, though that involved using a custom, XP-compatible, version of the Rust coding language ... If the SM project are to take a similar route, then backporting SM 2.53.x (FxESR 60.x-based) to WinXP/Vista doesn't "sound" unfeasible... But I seriously doubt they'll be interested ;) ...

I'm referring to an unofficial build being made by someone here, potentially. There's already a fork of that MailNews thing if I remember right by roytam1, as well as "IceApe", which appears to be SeaMonkey 2.49.4. I guess I just think people don't give SeaMonkey enough credit around these parts of the community. Waterfox has been rendered obsolete to me ever since Firefox started offering their own 64-bit builds in stable, which was the point of the browser in the first place...

2 hours ago, VistaLover said:

... You're probably mixing it up with WaterFox Classic :dubbio:, which is indeed based on Fx56 ...
SM 2.53.x branch is forked from a Firefox ESR 60.x code snapshot, specifically SM versions > 2.53.4 are based on FxESR 60.8 ...

https://en.wikipedia.org/wiki/SeaMonkey

I was going by the most recent SeaMonkey Meeting page on the Mozilla wiki, which refers to the engine as running on a heavily modded version of Gecko 56. (Or maybe I screwed up and misread 2022 as 2023, who knows. Lol.)

Edited by derpo
Link to comment
Share on other sites

2 hours ago, derpo said:

There's already a fork of that MailNews thing if I remember right by roytam1,
as well as "IceApe", which appears to be SeaMonkey 2.49.4.

... Both official applications (Interlink Mail & News by Binary Outcast and IceApe-UXP by Hyperbola) build upon the official UXP platform, which itself spawned from the Mozilla Firefox 52.6.0esr platform... Roy had already forked his own "smorgasbord" ;) version of UXP (where XP/Vista support was reinstated), so the release of the Mail News and Iceape forks was just a matter of adapting the front-end codebases to his own version of UXP... FTR, there's also Icedove offered, a fork of Icedove-UXP ... Common denominator here being UXP ;) ...

2 hours ago, derpo said:

I guess I just think people don't give SeaMonkey enough credit around these parts of the community.

... I don't think this is intentional, if it is a thing at all, but rather a consequence :( ... When the SM 2.49.x branch was still alive, members here did talk about it, but when the SM devs had no other option but to move away from it to a fresher codebase, sadly no longer compatible with XP (/Vista) (popular "among these parts of the community"), the "interest" of members here inevitably waned :whistle:...

2 hours ago, derpo said:

I was going by the most recent SeaMonkey Meeting page on the Mozilla wiki, which refers to the engine as running on a heavily modded version of Gecko 56.

Probably this :) ; whatever the Gecko version SM builds upon, it still uses Rust, and for someone "here" to "potentially" attempt an XP backport, he/she must find a way to backport that "Gecko version" to XP first, before dealing with the SM front-end code... That's why I mentioned Feodor[2] previously...
Unless we're talking about a SM 2.49.6+ application patched to build upon Roy's UXP platform; but that wouldn't be much different to existing Iceape 52, would it? :whistle:

Link to comment
Share on other sites

On 12/24/2022 at 9:13 AM, UCyborg said:

Newer Nextcloud versions using Unicode property escapes work with the new UXP additions . :thumbup@roytam1

On 1/26/2023 at 11:47 AM, UCyborg said:

Never mind, it doesn't work properly. Maybe the version that was loaded at my workplace back in December did, but it's full of defects now. File list doesn't load fully, there's no scrollbar, recent files don't load, refreshing just crashes the browser. Some critical errors:

SyntaxError: missing : after property id

 

Wow, that was quick! This is going to sound paranoid (because it is) but it sounds like the folks at NextCloud discovered - horrors! - that Pale Moon had started working with their Web site and immediately started looking for a new way to break Pale Moon. Can't have non-Google-approved browsers accessing our site - that would be a "security risk!"

No, I don't think that's what happened - probably just a coincidence - but given what folks seem to think "security" means nowadays, I can't rule it out....

Link to comment
Share on other sites

7 hours ago, VistaLover said:

Probably this :) ; whatever the Gecko version SM builds upon, it still uses Rust, and for someone "here" to "potentially" attempt an XP backport, he/she must find a way to backport that "Gecko version" to XP first, before dealing with the SM front-end code... That's why I mentioned Feodor[2] previously...
Unless we're talking about a SM 2.49.6+ application patched to build upon Roy's UXP platform; but that wouldn't be much different to existing Iceape 52, would it? :whistle:

This clears things up a lot more. Thanks!

Link to comment
Share on other sites

19 hours ago, Mathwiz said:

Wow, that was quick! This is going to sound paranoid (because it is) but it sounds like the folks at NextCloud discovered - horrors! - that Pale Moon had started working with their Web site and immediately started looking for a new way to break Pale Moon. Can't have non-Google-approved browsers accessing our site - that would be a "security risk!"

No, I don't think that's what happened - probably just a coincidence - but given what folks seem to think "security" means nowadays, I can't rule it out....

It's probably out of their radar sight rather than breaking Pale Moon deliberately. I suspect most devs in general, if they were to look into the browser, would dismiss it as being slow and archaic.

I just figured out I can actually check the version through my user on the instance running at workplace, apparently it's updated to the latest 25.0.3. Source code is here: https://github.com/nextcloud/server

I found there are 4 files, each containing 2 incompatible class definitions (can't find them on the above link though), running the snippets through Babel and adding Palefill rules to do some search and replace fixes the errors and can now refresh the page without crashing, but I couldn't figure out the CSS magic required to make scrolling work when there are too many files to show at once.

Link to comment
Share on other sites

23 minutes ago, UCyborg said:

It's probably out of their radar sight rather than breaking Pale Moon deliberately. I suspect most devs in general, if they were to look into the browser, would dismiss it as being slow and archaic.

AGREED!

It's actually quite narcissistic of the MSFN Community to "always conclude" that each and every time a web site is discovered to not work on our ANCIENT browsers that "developers" are out to get us.

I assure you that they have much more important things to do than maintain compatibility for ANCIENT browsers.

Link to comment
Share on other sites

2 hours ago, UCyborg said:

It's probably out of their radar sight rather than breaking Pale Moon deliberately.

1 hour ago, NotHereToPlayGames said:

It's actually quite narcissistic of the MSFN Community to "always conclude" that each and every time a web site is discovered to not work on our ANCIENT browsers that "developers" are out to get us.

C'mon, guys, get a grip! If you bothered to read my entire post, you should've known I was speaking tongue-in-cheek:

21 hours ago, Mathwiz said:

This is going to sound paranoid (because it is) but it sounds like

21 hours ago, Mathwiz said:

No, I don't think that's what happened - probably just a coincidence

@NotHereToPlayGames, you in particular should be ashamed! The whole point of the post was that MCP's so-called "ancient" browser was enhanced so that NextCloud did work - and then a few weeks later, it stopped working again!

No, I don't think NextCloud deliberately broke Pale Moon. But the coincidence was so striking, I think one could be excused for being a little suspicious in this case. Not "each and every time a web site is discovered not to work on our 'ancient' browsers" as you wrote.

Next time, try to read what I actually wrote, and give me the benefit of the doubt. OK?

Link to comment
Share on other sites

3 hours ago, UCyborg said:

I suspect most devs in general, if they were to look into the [Pale Moon] browser, would dismiss it as being slow and archaic.

Believe it or not, I sort of agree. Certainly with the "slow" part. It's especially ironic given that Pale Moon started out as simply Firefox  optimized for performance on Windows.

I may not like that Mozilla mostly started over with Quantum, but I have to admit that MCP is pushing FF 52's Javascript engine to the limit to get it to handle all the latest "Googlisms." It's surprising that it works as well as it does.

From the Web developer's standpoint though, I've written a fair number of very simple Web pages, and I absolutely cannot understand why any Web developer would rely as heavily on JavaScript as most do for tasks the Web server itself would be much more suited to do. It's almost (have to emphasize those disclaimers now, apparently) as if they were trying to make their Web pages as slow and inefficient as possible!

Edited by Mathwiz
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...