My Browser Builds (Part 4)

[Mathwiz]

17 minutes ago, VistaLover said:

I have, since long ago, performanceObserver enabled and here (yesterday's St52 32-bit) GT works as expected:

I love Firefox-based browsers, but the one thing I don't love about them is that they have way too many similar-sounding preferences! I too have dom.enable_performance_observer set to true, although I no longer remember why. I was thinking of dom.enable_performance_navigation_timing, which must be false (now the default value) for Google Translate to work, because the implementation is evidently different from what the Goog expects.

On 12/25/2022 at 7:23 PM, Mathwiz said:

As crazy as that sounds, it actually works! In this case credit for discovering the workaround goes not to Moonchild but to kris_88. More info here: https://forum.palemoon.org/viewtopic.php?p=234631#p234631

Does make me wonder, though, why the heck the Goog added performance navigation timing function calls to Google Translate's Javascript! On suspicion that it's yet another sneaky way to fingerprint Web browsers, I'd recommend turning it off even if it didn't break anything! Moonchild said he'd make the default "false" in the next PM release. Anyone needing it (probably just Web developers) can always turn it back on.

 

[VistaLover]

25 minutes ago, Mathwiz said:

I was thinking of dom.enable_performance_navigation_timing,
which must be false (now the default value) for Google Translate to work,

... Actually, that requirement is no longer true ... The linked report inside the official PM Forums was originally posted in mid-December of last year, as UCyborg once said , long ago in IT world time... Again, in Saturday's Serpent 52, 

dom.enable_performance_navigation_timing;true

browser restarted (for good measure), then "the whole page GT feature" was tested:

Result (you'd have to allow pop-ups from GT, first):

Whether this is due to a change on Google's side or to advancements on the platform's (UXP) side, I can't really tell ...

[OutlawHusbando]

1 hour ago, Mathwiz said:

I love Firefox-based browsers, but the one thing I don't love about them is that they have way too many similar-sounding preferences! I too have dom.enable_performance_observer set to true, although I no longer remember why. I was thinking of dom.enable_performance_navigation_timing, which must be false (now the default value) for Google Translate to work, because the implementation is evidently different from what the Goog expects.

 

The web has always been flaw, and even flawer since the day they introduced Navigation object and media CSS (allow font fingerprint WITHOUT JS), compare to Navigation object PerformanceObserver is still less evil, but still evil nonetheless.

 

And Navigation object is pure evil, it's just another layer of fingerprint that companies like Google, Facebook can use to track user, it exposes User-Agent, plugins, OS, timezone, almost everything.

 

Best case scenario we can get is the death of HTTP protocol as a whole, and rebuild the web from scratch because it's too late already, the web should be safer for everyone.

Edited March 19, 2023 by OutlawHusbando

[RamonUn]

9 hours ago, VistaLover said:

You can always go to about:config and toggle "dom.enable_performance_observer" to "true"; the reason it's not true by default/already is Moonchild's objection to it ...

I was not aware about this option before @UCyborg mentioned it, I tried it for a day and now and it works fine. I do think it makes GitHub significantly slower so I might disable it later, plus it seems to leek memory?. I kinda understand Moonchild's objection but I think it should still be enabled by default, because when you ship a Browser, Web compatibility should be of first priority, then it should be listed in the *Privacy options*, because it does cause privacy issues, If you have a GitHub account and are logged in this is not a concern at all as all your activities are already perfectly known by GitHub.

[OutlawHusbando]

1 hour ago, RamonUn said:

I was not aware about this option before @UCyborg mentioned it, I tried it for a day and now and it works fine. I do think it makes GitHub significantly slower so I might disable it later, plus it seems to leek memory?. I kinda understand Moonchild's objection but I think it should still be enabled by default, because when you ship a Browser, Web compatibility should be of first priority, then it should be listed in the *Privacy options*, because it does cause privacy issues, If you have a GitHub account and are logged in this is not a concern at all as all your activities are already perfectly known by GitHub.

It's still his decision to enable or disable it by default, there's no doubt, but our boy roytam can decide to switch it on because so far it doesn't violate anything.

[VistaLover]

Dear @roytam1 , I realise you're pressed for free time over this latest period, and I totally respect that, however ...

... I still get reliable/persistent/reproducible browser crashes in "xul.dll", as first reported previously here :

On 3/13/2023 at 11:20 PM, VistaLover said:

I have been suffering myself from instant crashes in xul.dll (presumably attributed to the same root cause ) when the below combination is met:
a) a WE userscript manager is installed and enabled (in St52), such as Violentmonkey
b) the GitHub download zip userscript has been installed and enabled
c) when browsing GitHub in general, you (unexpectedly) arrive to a GH 404 page, e.g.

https://github.com/ytdl-org/youtube-dl/issues/31950

 ... even with the most-up-to-date Serpent 52.9.0 package ; STR: 

1. Download and "install" package:
basilisk52-g4.8.win32-git-20230318-3219d2d-uxp-85f6a4929-xpmod.7z

2. Launch a fresh St52 profile.
3. Visit:

https://github.com/violentmonkey/violentmonkey/releases/tag/v2.14.0

and install file "violentmonkey-2.14.0.xpi" - FWIW, this is the EoS version for FxESR 52.9.x; the extension works as expected in Fx52+, but has some quirks in St52, due to MCP's faulty implementation of the abortController API (but this is material for another post ...).

4. Visit:

https://github.com/Mottie/GitHub-userscripts/wiki/GitHub-download-zip

and scroll to "Click this link to install from GitHub; or, install from GreasyFork or OpenUserJS."

Proceed to install from, e.g., GitHub and make sure the userscript is ENABLED

EDIT: To install the UserScript in VM-2.14.0, look here or here .

5. In a new browser tab, load either of:

https://github.com/ytdl-org/youtube-dl/issues/32500

https://github.com/JustOff.atom

Result: Instant crash:

Problem signature:
  Problem Event Name:	APPCRASH
  Application Name:	basilisk.exe
  Application Version:	4.8.6.8298
  Application Timestamp:	6411ec8e
  Fault Module Name:	xul.dll
  Fault Module Version:	4.8.6.8298
  Fault Module Timestamp:	6411ed8a
  Exception Code:	c0000005
  Exception Offset:	009c9623
  OS Version:	6.0.6003.2.2.0.768.3
  Locale ID:	1032
  Additional Information 1:	508f
  Additional Information 2:	13f7db7a784678d3cc8ffd137f83d688
  Additional Information 3:	a4fa
  Additional Information 4:	7911363c0f1bdc89f23d695c08a2ab86

The browser doesn't crash if that userscript is being disabled while browsing GitHub (but my workflow demands I have it enabled ) ; also, the browser doesn't crash if I revert to the St52 build from a fortnight ago, i.e. package:

basilisk52-g4.8.win32-git-20230304-3219d2d-uxp-33981efb4-xpmod.7z

... but that one is plagued by the "GH-timestamps-bug", so I'd rather not go back to it ...

Can you reproduce? Does the "Problem signature" above provide any indication at all?
This isn't a pressing thing for me, so you can deal with it as time permits, but it's very annoying here ; the two triggering GH URIs above are just samples, I may never know when St52 will crash on GH, with eventual data loss when it happens ...

Thanks for your hard work and perseverance into keeping our aging H/W and/or OSes in a "working" state; your coding time plus all expenses/cost needed to maintain the compiling machine(s) and server(s) is being immeasurably appreciated by this community here (and elsewhere, probably  ) !

Kind regards

Edited March 20, 2023 by VistaLover

[roytam1]

1 hour ago, VistaLover said:

Dear @roytam1 , I realise you're pressed for free time over this latest period, and I totally respect that, however ...

... I still get reliable/persistent/reproducible browser crashes in "xul.dll", as first reported previously here :

 ... even with the most-up-to-date Serpent 52.9.0 package ; STR: 

1. Download and "install" package:
basilisk52-g4.8.win32-git-20230318-3219d2d-uxp-85f6a4929-xpmod.7z

2. Launch a fresh St52 profile.
3. Visit:

https://github.com/violentmonkey/violentmonkey/releases/tag/v2.14.0

and install file "violentmonkey-2.14.0.xpi" - FWIW, this is the EoS version for FxESR 52.9.x; the extension works as expected in Fx52+, but has some quirks in St52, due to MCP's faulty implementation of the abortController API (but this is material for another post ...).

4. Visit:

https://github.com/Mottie/GitHub-userscripts/wiki/GitHub-download-zip

and scroll to "Click this link to install from GitHub; or, install from GreasyFork or OpenUserJS."

Proceed to install from, e.g., GitHub and make sure the userscript is ENABLED

5. In a new browser tab, load either of:

https://github.com/ytdl-org/youtube-dl/issues/32500

https://github.com/JustOff.atom

Result: Instant crash:

Problem signature:
  Problem Event Name:	APPCRASH
  Application Name:	basilisk.exe
  Application Version:	4.8.6.8298
  Application Timestamp:	6411ec8e
  Fault Module Name:	xul.dll
  Fault Module Version:	4.8.6.8298
  Fault Module Timestamp:	6411ed8a
  Exception Code:	c0000005
  Exception Offset:	009c9623
  OS Version:	6.0.6003.2.2.0.768.3
  Locale ID:	1032
  Additional Information 1:	508f
  Additional Information 2:	13f7db7a784678d3cc8ffd137f83d688
  Additional Information 3:	a4fa
  Additional Information 4:	7911363c0f1bdc89f23d695c08a2ab86

The browser doesn't crash if that userscript is being disabled while browsing GitHub (but my workflow demands I have it enabled ) ; also, the browser doesn't crash if I revert to the St52 build from a fortnight ago, i.e. package:

basilisk52-g4.8.win32-git-20230304-3219d2d-uxp-33981efb4-xpmod.7z

... but that one is plagued by the "GH-timestamps-bug", so I'd rather not go back to it ...

Can you reproduce? Does the "Problem signature" above provide any indication at all?
This isn't a pressing thing for me, so you can deal with it as time permits, but it's very annoying here ; the two triggering GH URIs above are just samples, I may never know when St52 will crash on GH, with eventual data loss when it happens ...

Thanks for your hard work and perseverance into keeping our aging H/W and/or OSes in a "working" state; your coding time plus all expenses/cost needed to maintain the compiling machine(s) and server(s) is being immeasurably appreciated by this community here (and elsewhere, probably  ) !

Kind regards

this is introduced by https://github.com/roytam1/UXP/commit/24572438a020f412b10c6c18708243c4a87fc9fb#diff-7ab2a050d29179e5a1da8888fdff365978f880431cdd44f301fb21bf502cca6bR1026

Edited March 19, 2023 by roytam1

[VistaLover]

8 minutes ago, roytam1 said:

this is introduced by
https://github.com/roytam1/UXP/commit/24572438a020f412b10c6c18708243c4a87fc9fb#diff-7ab2a050d29179e5a1da8888fdff365978f880431cdd44f301fb21bf502cca6bR1026

... Thanks for your immediate reply , especially that late on a Sunday night/Monday morning in your timezone ...
I can't possibly start thinking where this finding leaves "me" here as far as Serpent 52.9.0 is concerned, because the STR "mix" involves a WebExtension (Violentmonkey), whereas "upstream" have eradicated (since years ago) WE support from UXP/Basilisk, so don't code/test with WE in mind; OTOH, existing WE support inside Serpent 52/55 has been practically left unmaintained (not because of any fault of yours , "we" understand its current status is: "Use at your own risk") at the level present when the platform(s) was forked from Mozilla...

Unless there's something you yourself can code to "fix" this type of xul.dll crashes, I may have to look for "alternative" solutions ...

Thanks, goodnight and have a good new (working ) week  ...

[modnar]

Hey all!

Great new release!

I wonder why in recent releases of Serpent 52.9 (on XPSP3) scrolling through youtube short videos is more likely than not broken (I use screen resolution of 1680x1050). When loading a short it plays and when wanting to go to the next one with down arrow the browser goes there but then quite quickly jumps back up to previous one. This is quite frustrating. I do use ublock origin with the browser.

Thanks.

[Mathwiz]

5 hours ago, VistaLover said:

4. Visit:

https://github.com/Mottie/GitHub-userscripts/wiki/GitHub-download-zip

and scroll to "Click this link to install from GitHub; or, install from GreasyFork or OpenUserJS."

I don't know if this will help, but I had to roll back to VM v2.13.2 to complete that step. This was on latest St 52 but I suspect VM has actually been incompatible with St 52 since, well, "long ago in IT world time."

With 2.13.2 I did not experience a crash when clicking on the "not found" links.

15 hours ago, VistaLover said:

Actually, that requirement is no longer true ... The linked report inside the official PM Forums was originally posted in mid-December of last year, as UCyborg once said , long ago in IT world time.

An interesting discovery, but since our consensus seemed to be that dom.enable_performance_navigation_timing should be left false in any case:

On 12/25/2022 at 7:23 PM, Mathwiz said:

Does make me wonder, though, why the heck the Goog added performance navigation timing function calls to Google Translate's Javascript!

On 12/26/2022 at 9:20 AM, VistaLover said:

The usual reasons : 

1. Increase the amount of user-info (telemetry) they're harvesting via their "spyware" browser application,
2. undermine the competition and break older (aka "legacy") browser platforms at the same time...

See upstream #2053

Quote

There were apparently recent changes to have more data being passed back and forth with measure(), Firefox 103+.
This is apparently being pushed without fallback in Google Translate.

Google's implementation of the measure() function (measureOptions parameter) requires at minimum Fx103

... and since Moonchild apparently agrees (this pref now defaults to false), and since Google has heretofore been very clearly unwilling to change their code to accommodate older browsers, and since the only reason the question was brought up in the first place was confusion with a different but similar-sounding pref, there seemed little reason to recheck! I guess it's good that you rechecked anyway, so if we someday discover a Web site that requires this pref be set to true, we'll know that we no longer have to choose between that as-yet-undiscovered site and Google Translate.

Just a reminder that we started going down this rabbit hole because of an off-hand comment by @UCyborg:

On 3/18/2023 at 4:49 AM, UCyborg said:

PerformanceObserver is implemented in UXP, but MCP thinks it's evil so it's disabled by default - search for performance in about:config, I don't recall the exact pref name and I'm not at computer ATM.

Edit: It's dom.enable_performance_observer.

I never figured out why he mentioned that pref, but it appears GitHub requires it (sigh). I tend to agree with MC that it's a privacy hazard - and there's no straightforward way to enable it for specific sites (like, perhaps, GitHub) where you decide the benefit is worth the risk to privacy.

BTW the Edge download page has now decided to start working again in my "dirty" St 52 profile (which, like the "clean" profile, has the pref set to the default values of false) - I changed nothing.

16 hours ago, VistaLover said:

MS, in their infinite idiocy , used this piece of code to establish access to "their" downloads ; whatever happened to good ol' clickable links?

I agree 100%! The only thing I can think of is, when you click on one of M$'s download links (with @UCyborg's Palefill version - 1.25.4), you get a pop-up license agreement that you have to click the "I agree" box on before you can download the installer. But the installer is one of those "on-line" installers that's obviously far too small to contain Edge - instead it merely downloads Edge when you run it, so the installer could have popped up the license agreement itself. Who cares if someone wants to reverse-engineer (or otherwise violate M$'s terms) an "on-line" installer?

BTW, the installer fails on my Win 7 system with an error x'80000003', an error code not documented on M$'s help page.

[VistaLover]

2 hours ago, Mathwiz said:

when clicking on the "not found" links.

...Apologies... Forum's editor mishap ; step 5 in the STR should now have the correct links:

7 hours ago, VistaLover said:

5. In a new browser tab, load either of:

https://github.com/ytdl-org/youtube-dl/issues/32500

https://github.com/JustOff.atom

 

2 hours ago, Mathwiz said:

I don't know if this will help, but I had to roll back to VM v2.13.2 to complete that step. This was on latest St 52 but I suspect VM has actually been incompatible with St 52 since, well, "long ago in IT world time."

With 2.13.2 I did not experience a crash when clicking on the "not found" links.

Well, I had nothing to lose, so I did downgrade from VM-2.14.0 back to VM-2.13.2, as you suggested:

Then, with "GitHub download ZIP" enabled,

a simple visit to either one of the two (culprit) links will instantly provoke a full browser crash:

... and

This is, again, with latest St52 ... FWIW, the crashes still appear whether you disable the native WC implementation/use the palefill extension for GitHub ...

Edited March 19, 2023 by VistaLover

[roytam1]

6 hours ago, VistaLover said:

... Thanks for your immediate reply , especially that late on a Sunday night/Monday morning in your timezone ...
I can't possibly start thinking where this finding leaves "me" here as far as Serpent 52.9.0 is concerned, because the STR "mix" involves a WebExtension (Violentmonkey), whereas "upstream" have eradicated (since years ago) WE support from UXP/Basilisk, so don't code/test with WE in mind; OTOH, existing WE support inside Serpent 52/55 has been practically left unmaintained (not because of any fault of yours , "we" understand its current status is: "Use at your own risk") at the level present when the platform(s) was forked from Mozilla...

Unless there's something you yourself can code to "fix" this type of xul.dll crashes, I may have to look for "alternative" solutions ...

Thanks, goodnight and have a good new (working ) week  ...

try to fix that and it seems not crashing with those URLs:

https://github.com/roytam1/UXP/commit/af28af9f85dbdd09a9c11e33cab99f09a2699337

[VistaLover]

21 minutes ago, roytam1 said:

try to fix that and it seems not crashing with those URLs:

https://github.com/roytam1/UXP/commit/af28af9f85dbdd09a9c11e33cab99f09a2699337

! However, as the people in the UK say: "The proof is in the pudding" , so I'll be waiting for next St52 builds (Sat 25/03/2023 ?) with bated breath (I'm a Southern-European close to the Mediterranean Sea, patience is not a true virtue of mine ) ...

[VistaLover]

On 3/18/2023 at 11:05 AM, rereser said:

had a question about setting this for all sites ( // @match       *://*/* )
from the polyfill link NHTPG posted i think that is correct.

In Violentmonkey, I don't use myself:

// @match       *://*/*

but rather:

// @include     *

[VistaLover]

On 3/18/2023 at 3:29 PM, OutlawHusbando said:

If you guys are having trouble browsing Youtube and video services, like slowness, lagginess...
Check this tutorial: How to fix the broken web (Youtube & pals) .ft PM+MPV

... Thanks, but over here, you're mostly preaching to an XP/Vista 32-bit congregation ...

All the shinchiro compiled MPV (32-bit) builds target Win7SP1 as minimum OS requirement - you'll have to travel into the past to find the Vista EoS build, which was "mpv-0.32.0-157-git-20200223-g57ecfb4-i686_20200223" (from 37 months ago ); you'd have to travel way further back to find an XP-compatible MPV build (I don't remember off-hand, but the XP-users know it; from the 2015 era?) ...

As for yt-dlp, Vista SP2 32-bit is still officially supported for a few more months (or until CPython 3.7 becomes EoL), however XP is not; thanks to co-member @nicolaasjan, XP-compatible yt-dlp builds (be-it third party) are being currently offered (just look at his MSFN signature ) ...