My Browser Builds (Part 4)

[UCyborg]

I do have the feeling they're just piling up features for web compatibility on top of the old codebase that needs radical refresh. But could that refresh be done differently than Firefox's? Or it just has to stay that way because there is no other way and that's just how it is?

Relevant discussion I found.

Edited April 9, 2023 by UCyborg

[Saphir]

3 hours ago, UCyborg said:

I do have the feeling they're just piling up features for web compatibility on top of the old codebase that needs radical refresh.

If they would use a newer code-base as base code, they would lose all customization features - that is clearly a no-go. But it clearly would help if they would use multi-process - but that one was just in baby-steps during the time where the code base versions 52-56 have been out. 

And back-porting more multi-process code requires for sure Rust - which makes this also a no-go.

The main problem is that all modern web-pages and all modern ECMAScript/CSS features and drafts are designed to work only properly with multi-process browsers in mind - and if a single process browser visits such a page - or tries to make use of such standards and drafts it simply can't handle that properly as it was never intended to work with stuff like that correctly.

That is at least my point of view.

Edited April 10, 2023 by Saphir

[roytam1]

rebased my PM port to SP55, still lots of problems.

[Mathwiz]

4 hours ago, UCyborg said:

Relevant discussion I found.

Since it provides important context but is only a few lines longer, here's the actual start of that thread: https://news.ycombinator.com/item?id=15278883

And that was written six years ago. Things have only gotten worse. For example, the Big Four are now the Big Three since Microsoft threw in the towel and jumped on the Cr bandwagon.

2 hours ago, Saphir said:

And back-porting more multi-process code requires for sure Rust - which makes this also a no-go.

I don't think Rust is a no-go for MCP, since they're targeting Win 7 and up. It would certainly complicate @roytam1's job and our lives, but @feodor2 has found ways to compile Rust code for XP; e.g., MyPal 68 - so Rust wouldn't necessarily be a show-stopper for us either.

M10s doesn't fully solve the memory issues though. I have m10s active at work (32-bit WinXP) and while it lets me use Outlook.com for a while, eventually the process gets over 1 GB (!), the CPU usage goes to 99%, and I have to close the tab, wait for everything to calm down, then click "Undo Close Tab," after which I'm fine for a while longer until the cycle repeats. They really need to limit the cache size somehow, Rust or no Rust.

2 hours ago, Saphir said:

The main problem is that all modern web-pages and all modern ECMAScript/CSS features and drafts are designed to work only properly with multi-process browsers in mind

It's worse than that: modern web pages are designed to work properly only on Chromium-based browsers. (Well, plus Safari, but I suspect if we could see Safari's code, it would look more like Cr than even modern FF.

Whether we like it or not (in my case, definitely not, but it doesn't change the reality), Google's Chrome and Cr-based offshoots like Edge and (barely) Opera dominate today's browser landscape. While I criticize Mozilla for duplicating way too much of Chrome's look and feel, we're lucky that even modern FF exists as something of an alternative at all, let alone UXP.

[roytam1]

6 minutes ago, Mathwiz said:

I don't think Rust is a no-go for MCP, since they're targeting Win 7 and up. It would certainly complicate @roytam1's job and our lives, but @feodor2 has found ways to compile Rust code for XP; e.g., MyPal 68 - so Rust wouldn't necessarily be a show-stopper for us either.

it is still a problem that mypal68 can't produce x64 build, since rustc/rust-stdlib still has some problems that feodor2 doesn't fix/workaround in the moment.

[cmccaff1]

3 hours ago, roytam1 said:

rebased my PM port to SP55, still lots of problems.

Just want to say that I wish you good fortunes going forward with the rebasing! Currently using the latest NM28 build in POSReady 2009 (my favorite version of XP now and the one I plan to stick with on hardware that can natively run it), and it works beautifully. (It now seems to truly support nullish coalescing/optional chaining without needing to install palefill, which is fantastic!)
I respect all the hard work you've done and am very excited to continue testing XP compatible software. If I can be of any help in the future I'll do my best. Thank you for doing what you do, Roy! (And many thanks to all others keeping the legendary XP useful!)

[Saphir]

8 hours ago, roytam1 said:

rebased my PM port to SP55, still lots of problems.

@roytam1 What is the benefit of 55 over 52?

Anyway, i hope it works out for you, and that it is not impossible, as the UXP/Pale Moon project was also forced to return to 52 when trying to to it with that one.

Edited April 10, 2023 by Saphir

[Saphir]

9 hours ago, Mathwiz said:

I don't think Rust is a no-go for MCP, since they're targeting Win 7 and up. It would certainly complicate @roytam1's job and our lives, but @feodor2 has found ways to compile Rust code for XP; e.g., MyPal 68 - so Rust wouldn't necessarily be a show-stopper for us either.

It's worse than that: modern web pages are designed to work properly only on Chromium-based browsers.

@Mathwiz But the thing is UXP uses no Rust, so it is basically useless cruft to add that back. There is just minimalist Rust usage in code bases below 57 - what for a use would it be to restore this again? Rust clearly makes only sense if you would use a code base beyond 57 as planned base code for any theoretical future release (and that would be a no-go again as the classic UI with it's unique features could not be brought forward) - 100% flawlessly working Multi-Process usage in an engine below 57 is a goal basically impossible.

I would say there are 2 defining moments in Mozilla's own timeline:
- Firefox 0.x-56 - the era of customization and being different towards Chrome
- Firefox 57 - ??? - the era of minimalism and simplicity - "maximum Chrome user compatibility"

And yeah, they are optimized for Chrome - but what is the defining feature what Chrome uses? Multi-process - UXP web compatibility issues are are totally unique problem.

Edited April 10, 2023 by Saphir

[roytam1]

14 minutes ago, Saphir said:

@roytam1 What is the benefit of 55 over 52?

Anyway, i hope it works out for you, and that it is not impossible, as the UXP/Pale Moon project was also forced to return to 52 when trying to to it with that one.

they're just very similar, and this porting is just for fun.

[UCyborg]

@Mathwiz
Aye, supporting convoluted web as-it-is is a daunting task. I'm just curious what would happen if you threw a huge budget at the project and get the army of engineers working on it while keeping the existing philosophy. Judging from SeaMonkey, it may be possible to push just a bit more snappiness out of a single-process browser at least. The single-process vs multi-process is delicate matter as it would immediately increase base resource footprint. I see why they're against multi-process, I would likely stay with single-process even if Pale Moon supported both modes and multi-process worked with all extensions.

@RamonUn
Agreed, cache management must be difficult to keep track of.

38 minutes ago, roytam1 said:

they're just very similar, and this porting is just for fun.

I have to say I'm a bit envious of what some people manage to consider fun.

[Saphir]

5 minutes ago, UCyborg said:

I would likely stay with single-process even if Pale Moon supported both modes and multi-process worked with all extensions.

 

@UCyborg Same, we should keep in mind that multi-process opens a hell-hole of security issues and tons of bugs. This complexity introduced with a multi-process based system is nothing to take lightly.

Edited April 10, 2023 by Saphir

[roytam1]

23 minutes ago, Saphir said:

@UCyborg Same, we should keep in mind that multi-process opens a hell-hole of security issues and tons of bugs. This complexity introduced with a multi-process based system is nothing to take lightly.

thats a hole connects to abyss. and we don't know the thing comes from abyss is a bless or a curse.

[roytam1]

1 hour ago, UCyborg said:

I have to say I'm a bit envious of what some people manage to consider fun.

and actually you can experience how MC frustrated on trying to port PM front-end to moebius but failed because of other browser components requiring major reverts/rewrites to get PM front-end working.

this progress "itself" is fun.

 

just I don't have enough wisdom to make it go further this time in the moment. maybe I will revisit it again in the future.

Edited April 10, 2023 by roytam1

[NotHereToPlayGames]

1 hour ago, UCyborg said:

I have to say I'm a bit envious of what some people manage to consider fun.

[Mathwiz]

16 hours ago, Saphir said:

But the thing is UXP uses no Rust, so it is basically useless cruft to add that back.

But that's not what you said earlier:

On 4/9/2023 at 5:47 PM, Saphir said:

And back-porting more multi-process code requires for sure Rust - which makes this also a no-go.

So first it was, UXP needs Rust to properly implement m10s mode; now adding Rust code to UXP would just be "useless cruft." Which is it?

I also sense a straw-man argument. I didn't say MCP should incorporate Rust code into UXP, only that they could, if they felt it was necessary. (Actually, I'm surprised they didn't do so back when MAT was there, just to make our lives more difficult.)

16 hours ago, Saphir said:

And yeah, they are optimized for Chrome - but what is the defining feature what Chrome uses? Multi-process

Come on; the "defining feature" of Chrome isn't multi-process, it's Googlisms: frequent additions to JS/CSS, proposed by Google, Inc., that require equally frequent browser updates to implement, thus ensuring obsolescence of any browser not backed by a development team large enough to implement the continual flow of new Googlisms. (Of course we have seen at least one "Mozilla-ism," so Google isn't the only one playing this game; but it's quite clear that Google is far and away the dominant player.)

16 hours ago, UCyborg said:

I'm just curious what would happen if you threw a huge budget at the project and get the army of engineers working on it while keeping the existing philosophy.

In theory that would probably work! The only problem is, companies at that scale are less committed to "philosophy," so it's easier for them either to just start with the dominant engine - Cr - and add their own flourishes (M$), or to work out a tech-sharing agreement with Google (Mozilla and - probably - Apple).

16 hours ago, UCyborg said:

Judging from SeaMonkey, it may be possible to push just a bit more snappiness out of a single-process browser at least.

That is true as well.

16 hours ago, UCyborg said:

The single-process vs multi-process is delicate matter as it would immediately increase base resource footprint. I see why they're against multi-process, I would likely stay with single-process even if Pale Moon supported both modes and multi-process worked with all extensions.

E10s is certainly not for the smaller, slower systems many users are running XP on, and it makes less difference on 64-bit systems with essentially unlimited virtual RAM. It's probably best suited for larger, faster 32-bit systems, since you can use more virtual RAM without "maxing out" and crashing a single process.

One nice thing about the implementation we have in Serpent is that it can keep e10s on a rather tight leash, limiting the number of processes to fit your PC's resources. Cr, OTOH, spawns processes like crazy - often several per tab. Even though they're generally rather small, they can quickly overwhelm a smaller PC if you open a lot of tabs.