My Browser Builds (Part 4)

[Milkinis]

1 hour ago, ClassicNick said:

roytam1's UXP browsers already run the Goanna 6.1 rendering engine. @roytam1

I have not updated mine since last summer. how do you check this out ?

[Milkinis]

2 hours ago, roytam1 said:

function depends on platform code (i.e. UXP) which MCP removed such function from platform code long time ago, I don't think people can add back this without forking platform code.

if one takes over the dead Basilisk project and keeps using the same UXP platform with no major code changes I see no reason to use it over the original Palemoon

now if @basilisk-dev decides to bring Basilisk back with multi-process enabled by default and many other good features that the Palemoon doesn't have then I think it could be a cool workaround.

I also started using New Moon 28 but switched to Serpent 52 as soon as I knew it had multi-process functionality

[ClassicNick]

19 minutes ago, Milkinis said:

I have not updated mine since last summer. how do you check this out ?

If you read the change logs between roytam1's UXP commit history, and Moonchild/upstream's UXP commit history, you will be able to draw the conclusion that the 2 UXP code bases are nearly identical. Following upstream UXP development, you will know that the defining features of Goanna 6.0 were the implementation of Regular Expression named capture groups, Regular Expression unicode property escapes, and Regular Expression lookaround/lookbehind, and the defining features of Goanna 6.1 were additions to the Shadow DOM v1 implementation (see issue "#2135"), along with a bug fix to make Custom Elements v1 work properly, which allowed "dom.webcomponents.enabled" to be set to "true" by default (see about:config). Also see pages 55, and 61 of this thread to view my favourite change logs of the UXP browser builds and search for issue #1361 on page 55, and #2135 on page 61.

https://www.palemoon.org/releasenotes.shtml

https://repo.palemoon.org/MoonchildProductions/UXP/commits/branch/master

https://github.com/roytam1/UXP/tree/custom

https://github.com/roytam1/UXP/blob/custom/config/milestone.txt

https://repo.palemoon.org/MoonchildProductions/UXP/src/branch/master/config/milestone.txt

[roytam1]

16 hours ago, AstroSkipper said:

In KM76.4.7-Goanna-20230325, there is another issue, even in a new, clean profile. Right-clicking on a toolbar, then pointing with the mouse to the entry Toolbars, and finally clicking onto the entry Options leads immediately to a browser crash. Here are two screenshots:

this function seems to be broken for a quite long time

[AstroSkipper]

12 hours ago, roytam1 said:

On 3/25/2023 at 4:20 PM, AstroSkipper said:

In KM76.4.7-Goanna-20230325, there is another issue, even in a new, clean profile. Right-clicking on a toolbar, then pointing with the mouse to the entry Toolbars, and finally clicking onto the entry Options leads immediately to a browser crash. Here are two screenshots:

this function seems to be broken for a quite long time

Was actually a total coincidence that I came across this issue. I had to create a new profile to check the other issue with the search engines. In the process, I also wanted to reconfigure the toolbars and suddenly the crash. Can this be fixed? 

Edited March 26, 2023 by AstroSkipper
correction

[roytam1]

13 minutes ago, AstroSkipper said:

I also wanted to reconfigure the toolnars and suddenly the crash. Can this be fixed?

better press [F2] to call out prefs windows instead.

[AstroSkipper]

36 minutes ago, roytam1 said:

50 minutes ago, AstroSkipper said:

I also wanted to reconfigure the toolnars and suddenly the crash. Can this be fixed?

better press [F2] to call out prefs windows instead.

Thanks for the tip! There are different ways to configure the toolbars. I know. But unfortunately, that doesn't actually answer my question. And do you have any idea why old profiles produce issues in terms of search engines as I confirmed here? 

Kind regards, AstroSkipper 

Edited March 26, 2023 by AstroSkipper
Update of content

[luweitest]

17 hours ago, VistaLover said:

... I can also confirm that statement :

accessing it from Southern Europe; I'm not familiar with that site, but is the server/hostname "forums.internetfreedom.org" located outside of the GFW (I assume so, because. err, "internetfreedom" is non-existent inside mainland China ) ? Since St52 has its own certificate store, XP's deficient OS CA store shouldn't matter in this case... 

Does the GFW block access to "fankui.dongtaiwang.net" issued server certs ? (and I see the "taiwan" string in that hostname, so it's more than probable ) ; here's a screengrab of the certs chain when validating the site's certificate:

Are you able to VPN/tunnel your way out the GFW and reach that site securely? if yes, you could export the server cert (expires on June 6th 2023) and import it to St52's cert store for the duration it's valid... Have you checked whether the site loads securely on a fresh St52 profile? Have you also tried unselecting the option

"Query OCSP responder servers to confirm the current validity of certificates"

in "about:preferences#advanced -> Certificates" ?

If you can browse SO/SU and similar sites, you'll see that solutions downgrading HTTPS to plain HTTP are not desirable and, hence, very difficult to come across (and your particular use-case is indeed a niche one) ...

I should have tried fresh profile first (so obvious that something must have blinded my eyes): yes the fresh profile works! And after seeing your certificate picture I find https://fankui.dongtaiwang.net/* works also in my profile! So there must be a configuration in my profile that prevents mismatch of certificate's host name and the URL's host. Where is it?   There is no such configuration. The problem is that the rule "internetfreedom.org" in my subscription of rule set for automatic proxy switching does not function for URL "https://forums.internetfreedom.org". The rule set is supposed to comply with Adblock's syntax. I manually added a rule "||internetfreedom.org" and now everything's back to normal.

And although this case is resolved, the need for downgrading HTTPS to plain HTTP is still valid, because there are times the GFW interrupts TLS connection through proxy|VPN, by recognition of TLS negotiation pattern that ought to be hided. At those times the HTTP page are more likely accessible than HTTPS. I know it is not recommended in security or privacy concern, but accessibility goes first in most cases.

ps. Isn't it suspicious if a page uses certificate that belongs to another domain? Although in previous example I know "fankui.dongtaiwang.net" and "forums.internetfreedom.org" is the same host, I think my profile is right in preventing this kind of mismatch, only it should clearly state so, not give out a time-out.  I hope this kind of mismatch should be noted by browser, and give option to proceed or block.

 

Edited March 26, 2023 by luweitest
correction

[Mathwiz]

On 3/18/2023 at 9:44 PM, luweitest said:

The new Bing needs Edge browser to work.

Sounds to me like another genius move by Micro$oft: make sure even fewer folks use Bing!

On 3/20/2023 at 12:31 PM, VistaLover said:

chase.com don't allow anything older than Win7

Hasn't affected me, since I routinely spoof Win 7 or 8.1 in my UAs; but Chase long ago fell for the FUD that old OSes are inherently too insecure. I remember years ago when they blocked their own Android app on Android 6 for the same reason. Of course that just meant I had to use Chrome instead of their app.

On 3/23/2023 at 9:47 PM, Milkinis said:

'So, you want to invite people that are running malware riddled machines to have respectful online communications about web browsers?''

this one is must be living in a world apart.... 

Maybe Moonbat works for Chase?

On 3/24/2023 at 5:54 PM, UCyborg said:

Why is the sky blue?

https://en.wikipedia.org/wiki/Rayleigh_scattering. Sorry, couldn't resist!

On 3/24/2023 at 7:17 PM, VistaLover said:

app.feedback.baseURL

I checked mine, and mine is user-set to

... which is better, but obviously way out of date! Problem with pointing it to this thread is that it, too, will be locked someday....

On 3/24/2023 at 11:56 PM, Milkinis said:

why doesn't Basilisk support multi process mode by default ?

Multi-process mode was removed from Basilisk by MCP before @basilisk-dev got ahold of it. @roytam1 omitted those particular commits, so it can be enabled in Serpent, but even Serpent doesn't have it enabled by default!

IIRC, multi-process mode was still in its infancy when the two Basilisk versions were forked from Firefox. Even FF 52 disables it by default on XP.

That said, I've had generally good results running with it enabled, except for some incompatible add-ons; notably Palefill and Classic Add-ons Archive. (The latter has a "hack" which was written for Waterfox but can be enabled for Serpent, which makes CAA open in a single-process mode window.)

10 hours ago, luweitest said:

Isn't it suspicious if a page uses certificate that belongs to another domain? I hope this kind of mismatch should be noted by browser, and give option to proceed or block.

If one site hosts multiple domains, the certificate will typically include a Subject Alternative Name for each domain hosted at that site. As long as the domain you're accessing is one of the certificate's SANs, the browser shouldn't give a warning. But if the domain isn't listed as a SAN, a warning should appear.

[jumper]

22 hours ago, luweitest said:

the need for downgrading HTTPS to plain HTTP is still valid

Create a bookmarklet with (or type into the address box) the following script:

javascript:document.body.innerHTML.split('https://').join('http://')

 

[VistaLover]

17 hours ago, Mathwiz said:

On 3/19/2023 at 4:44 AM, luweitest said:

The new Bing needs Edge browser to work.

Sounds to me like another genius move by Micro$oft: make sure even fewer folks use Bing!

... It's actually their new "offspring", OpenAI-based, supposed to be "more powerful" than ChatGPT:

https://blogs.microsoft.com/blog/2023/02/07/reinventing-search-with-a-new-ai-powered-microsoft-bing-and-edge-your-copilot-for-the-web/

17 hours ago, Mathwiz said:

Problem with pointing it to this thread is that it, too, will be locked someday....

... And Roy's choice is:

https://github.com/roytam1/basilisk55/commit/babf7e8e5c79cab7ea504f16fab609253e047ce8 =>

https://msfn.org/board/forum/201-browsers-working-on-older-nt-family-oses/

17 hours ago, Mathwiz said:

IIRC, multi-process mode was still in its infancy when the two Basilisk versions were forked from Firefox.
Even FF 52 disables it by default on XP.

Quite right ; at that time, Fx did support both XUL+WE extensions, and while WE are inherently e10s-compatible, not all XUL ones had been rewritten to support it; their authors became less "enthused" (to put it mildly ) when Mozilla announced XUL support would be axed in "Quantum" (Fx57+) ...

Being on Vista SP2 x86 myself, e10s is enabled in my Fx-52.9.1 (32-bit) "nostalgia/test" copy, however I don't use nor recommend myself e10s on St52/St55; the platforms (UXP Take 2 / UXP Take 1 = moebius) were significantly modified by upstream compared to their respective Mozilla forkpoints (52.6.0/53.0a1), not taking at all the underlying (but dormant) multiprocess support code into account; as posted already by others, that support was later excised completely from the "official" UXP code; "we" have kept these e10s vestiges inside "our" UXP tree, but no-one upstream (of course) or downstream (Roy) checks how well/bad these vestiges behave now, when enabled, with current UXP platform snapshots; St52 has also kept vestigial support for Fx52-level "Container Tabs" (off by default) and WEs, but, like e10s, those platform features, no longer present in official Basilisk, aren't being maintained at all by Roy...

All these extra features are in a "Use at your own risk" status; for e10s specifically, you should definitely back up your profile (to have a single process one to revert to if/when things turn sour ) before enabling it, and making frequent profile backups once on e10s isn't a bad idea either ...

To give credit to people requesting e10s in their browsers, it's mostly due to the way website design has grown to become over the last years : the major league of browsers, Chromium-based ones and Firefox, have, since long ago,, native multiprocess support, and it's those browsers that are being targeted by web devs and web frameworks; this has resulted in the current web abomination where every independent browser tab runs a "web app", downloading tens of MiBs of JS code that has to be rendered locally by the browser's engine; this is especially true on "popular" social media portals (facebook, instagram, twitter, etc.) and "chat" apps (e.g. Discord), exacerbated by the concurrent use of a multitude of rich media (HD images/GIFs, HD video, audio, WebRTC video+audio, etc) ...

While single process engines were "fine" a decade or more ago, they're more likely to "run out of O2 and choke to death" when asked to deal with the modern web, especially on our older H/W and OSes - but do also note that e10s works best on more recent H/W, where ample RAM and CPU is being made available to the multiprocess-enabled browser core ...

[VistaLover]

19 hours ago, Mathwiz said:

On 3/26/2023 at 6:33 PM, luweitest said:

Isn't it suspicious if a page uses certificate that belongs to another domain?
I hope this kind of mismatch should be noted by browser, and give option to proceed or block.

If one site hosts multiple domains, the certificate will typically include a Subject Alternative Name for each domain hosted at that site. As long as the domain you're accessing is one of the certificate's SANs, the browser shouldn't give a warning. But if the domain isn't listed as a SAN, a warning should appear.

@luweitest : Mathwiz is right ; below is a capture of the "SAN field" of the server certificate on "forums.internetfreedom.org":

 

[AstroSkipper]

33 minutes ago, VistaLover said:

@luweitest : Mathwiz is right ; below is a capture of the "SAN field" of the server certificate on "forums.internetfreedom.org":

 

Yep! A deeper look at the (server) certificates is always a good idea.

[VistaLover]

I have been running last Saturday's St52 (32-bit) build (BuildID=20230324153850) for a whole 3 days now and can confirm that the "xul.dll" crashes I first spoke of here no longer happen ; so it was indeed Bugzilla #1440809 (landing first on Fx60) that had to be applied to "our" UXP tree to get those crashes fixed... Many thanks  (FWIW, don't "upstream" also need this fix, or is it specifically tied to WebExtensions ? ).

Speaking of "xul.dll" crashes, another type of them (see #2176) was addressed by upstream in PR #2178, that fix has already been transferred to "our' tree and will be included in the next UXP-based releases (Sat, Apr 1st 2023) .

[AstroSkipper]

I also had a few crashes of xul.dll today, in the most recent release of New Moon 28 (2023-03-24), though. Here are two screenshots of these events:

Edited March 28, 2023 by AstroSkipper
Update of content