My Browser Builds (Part 5)

[Jody Thornton]

On 2/26/2024 at 11:45 AM, basilisk-dev said:

I am not doing this, I considered doing it to prevent buggy code being pushed to roytam1's users, but I never decided to actually go forward with it.

What's sad is that roytam1 continues to release code to his users that has not been verified as production ready. Code in the master branch of upstream UXP or upstream Basilisk is not always production ready. I have seen issues reported on MSFN for roytam1's builds because he was pulling code from master branches before they were ready. He is doing a disservice to his users by giving them potentially buggy code.

You seem reasonable.  I wish you would also take over Tobin's Interlink project so that those of us who like it can have an x64 version of it.  Roytam1 refuses to oblige,

Sigh!

[NotHereToPlayGames]

I think you are overthinking.  There really is NO REASON to make an x64 version.

I'm more OCD then the next guy, but to have it x64 just because everything else you use is x64 is not really a justifiable reason.

[VistaLover]

15 hours ago, Mathwiz said:

replaced path

chrome/pdfjs/content in omni.ja

with that "newer" (by 1 month) code.

... Besides

.\browser\!omni.ja\chrome\pdfjs\content\*

... I find some locale files are also relevant:

.\browser\!omni.ja\chrome\en-US\locale\pdfviewer\*

(St52) ; have these been taken into account while "testing" ? 

[Jody Thornton]

12 hours ago, NotHereToPlayGames said:

I think you are overthinking.  There really is NO REASON to make an x64 version.

I'm more OCD then the next guy, but to have it x64 just because everything else you use is x64 is not really a justifiable reason.

To you it isn't justifiable, but the application WAS originally x64.  Your lack of agreement doesn't make me wrong.  I want x64 applications on an x64 OS.  Nothing unreasonable able that at all.  Plus I would think the XP x64 Edition folks would love it.  Anyway, I'll remain stubborn.

[Mathwiz]

11 hours ago, VistaLover said:

I find some locale files are also relevant:

.\browser\!omni.ja\chrome\en-US\locale\pdfviewer\*

Well, as it turns out, there are some differences between the downloaded pdf.js releases, and the one built into omni.ja. Figures. (Couldn't make it simple, could you, Mozilla?)

In the downloaded releases, the locale files are in a "web" subfolder under the first path; not in a separate branch of the directory tree, as in the version built into omni.ja. I haven't yet determined whether the replaced l10n.js accesses the locale data from the new subfolder under "web" Further testing will be needed to figure this thing out completely

Edit: Still working on it, but I have figured out that the locale data built into omni.ja is US English only; the locale data in the standalone version is multilingual. So if I can figure this out, at least pdf.js will start working in other languages....

What have I gotten myself into? Oh, well, I can always just give up....

Edited March 5 by Mathwiz

[NotHereToPlayGames]

17 hours ago, Jody Thornton said:

Roytam1 refuses to oblige,

4 hours ago, Jody Thornton said:

Anyway, I'll remain stubborn.

If you think this is going to win the developer over to your side of thinking, "all the power to you".  I don't see it working though.  

[Jody Thornton]

4 hours ago, NotHereToPlayGames said:

If you think this is going to win the developer over to your side of thinking, "all the power to you".  I don't see it working though.  

Oh neither do I.  Although I have seen stranger changes of heart, so I never say never.

Besides, some of the best things I've ever achieved I had to apply pressure to get.  It was worth it.  No, you don't win 'em all, but you do win some.

[Mathwiz]

On 3/4/2024 at 7:38 AM, NotHereToPlayGames said:

There really is NO REASON to make an x64 version.

I tend to agree - but there's also no reason not to. The main reasons for making 64-bit versions of programs are to address large amounts of RAM in a single process, and to boost performance. Neither is as important for email clients as for browsers.

But @Jody Thornton wants one. I could see making it a low-priority project (not much demand), but unless there's something that just won't easily compile in 64-bit mode, I see no harm in giving it to him. The only downside is that the file would be slightly larger (and of course it would only run on 64-bit machines).

23 hours ago, Mathwiz said:

What have I gotten myself into? Oh, well, I can always just give up....

I made a bit of progress on this last night. The "build" folder is a drop-in replacement. The "web" folder is almost a drop-in replacement, but you do have to make some changes to viewer.js and viewer.html. I got viewer.js figured out last night. I'll see if I can get viewer.html figured out tonight, then I'll see how new the version can get before the Javascript becomes hopelessly incompatible.

Edit: I got it sorted and am up to version 2.5.207 from June 1, 2020. This is the last version with the traditional UI; version 2.6 has a "Photon-like" UI. 2.5 has a couple more buttons but it looks and acts pretty much the same.

Version 1.7:

Version 2.5:

Edited March 6 by Mathwiz

[j7n]

Google changed something. When I go to a YouTube page and scroll to the comments section, New Moon now crashes. It was working yesterday and earlier.

[roytam1]

2 hours ago, j7n said:

Google changed something. When I go to a YouTube page and scroll to the comments section, New Moon now crashes. It was working yesterday and earlier.

can't reproduce here, can you try with new profile?

[j7n]

Ok, seems like clearing the cache may have helped.

[luweitest]

Report: 

After upgrade Palefill 1.27 to 1.28, Github do not work in multi-threading mode of Serpent52 (2024-02-23). The page shows:

------------------------------------------------------------------------------------------------------------------------------------------------

Content Encoding Error
The page you are trying to view cannot be shown because it uses an invalid or unsupported form of compression.

------------------------------------------------------------------------------------------------------------------------------------------------

Disabling Palefill could solve it.

And in any case, Palefill 1.27 or 1.28 or disabled, multi-threading or not, Github show blank page like this one:

https://github.com/graemeg/xananews/blob/master/README.txt

 

[AstroSkipper]

20 minutes ago, luweitest said:

Report: 

After upgrade Palefill 1.27 to 1.28, Github do not work in multi-threading mode of Serpent52 (2024-02-23). The page shows:

------------------------------------------------------------------------------------------------------------------------------------------------

Content Encoding Error
The page you are trying to view cannot be shown because it uses an invalid or unsupported form of compression.

------------------------------------------------------------------------------------------------------------------------------------------------

Disabling Palefill could solve it.

And in any case, Palefill 1.27 or 1.28 or disabled, multi-threading or not, Github show blank page like this one:

https://github.com/graemeg/xananews/blob/master/README.txt

 

I can't observe this problem in the most recent version of New Moon 28.10.7a1 (32-bit) (2024-02-23) with Palefill 1.28 enabled. This site seems to work. Here is a screenshot:



Cheers, AstroSkipper

[AstroSkipper]

9 minutes ago, AstroSkipper said:

41 minutes ago, luweitest said:

Report: 

After upgrade Palefill 1.27 to 1.28, Github do not work in multi-threading mode of Serpent52 (2024-02-23). The page shows:

------------------------------------------------------------------------------------------------------------------------------------------------

Content Encoding Error
The page you are trying to view cannot be shown because it uses an invalid or unsupported form of compression.

------------------------------------------------------------------------------------------------------------------------------------------------

Disabling Palefill could solve it.

And in any case, Palefill 1.27 or 1.28 or disabled, multi-threading or not, Github show blank page like this one:

https://github.com/graemeg/xananews/blob/master/README.txt

 

Expand  

I can't observe this problem in the most recent version of New Moon 28.10.7a1 (32-bit) (2024-02-23) with Palefill 1.28 enabled. This site seems to work. Here is a screenshot:



Cheers, AstroSkipper

Same applies to the most recent version of Serpent 52 with Palefill 1.28 enabled. No problems here as you can see in this screenshot:



Cheers, AstroSkipper

[RamonUn]

1 hour ago, luweitest said:

After upgrade Palefill 1.27 to 1.28, Github do not work in multi-threading mode of Serpent52 (2024-02-23). The page shows:

Some plugins do not work properly with multi-process mode, it was already discussed in the past and it is an Old Firefox bug that would be very hard to fix. Because PaleMoon and Basilisk are not to be used in multi-process mode the Issue can only manifest itself on Serpent. You will need to disable multi-process mde if you want to use palefill or to disable palefill.