My Browser Builds (Part 2)

[Sampei.Nihira]

1 hour ago, roytam1 said:

<OT>

I'm sorry for your loss. Hope your government can further inspect if the death is related to vaccine or not.

and for me, I got my first dose of BNT few weeks ago and will get second dose on Friday, hope everything will be fine.

</OT>

<OT>

No, people too old have no chance of investigation,they definitely have other diseases,who does not have them at a certain age.
The European Medicines Agency has determined that the benefits of vaccines outweigh the risks, for the government of my country it is enough.
Only young people have any possibility of investigation with a chance of success.
Otherwise, in the end, you get nothing and you have to pay the high court fees.

 

In my country many deaths per day, especially Astrazeneca, and certainly the number is underestimated:

https://www.ilmessaggero.it/salute/storie/astrazeneca_genova_morta_insegnante_ospedale_san_martino_cosa_e_successo_ultime_notizie_news-5877548.html

 

</OT>

 

 

Edited April 4, 2021 by Sampei.Nihira

[Sampei.Nihira]

Classic Add-ons Archive by Just Off has been removed from the Black List:

 

https://repo.palemoon.org/MoonchildProductions/Pale-Moon/commit/ef31a26d22455c57382401721306d2ce7c568820

probably because of this:

https://forum.palemoon.org/viewtopic.php?f=46&p=212376#p212376

 

Edited April 6, 2021 by Sampei.Nihira

[nicolaasjan]

34 minutes ago, Sampei.Nihira said:

Classic Add-ons Archive by Just Off has been removed from the Black List:

 

https://repo.palemoon.org/MoonchildProductions/Pale-Moon/commit/ef31a26d22455c57382401721306d2ce7c568820

probably because of this:

https://forum.palemoon.org/viewtopic.php?f=46&p=212376#p212376

 

I see...

Strange things happening there indeed.

I mentioned the CookieKeeper add-on in that thread and even got a (not rude) answer from M.A.T....

But I'm not affected by the blacklist at all:

[VistaLover]

On 4/4/2021 at 1:55 AM, DanR20 said:

Twitter is having firefox fits again. Using the latest release+ user string, I'm getting this message in 52 and 55:
"Something went wrong, but don’t fret — let’s give it another shot."
Changing the string to this and it comes in again:

Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0

Twitter related upstream change targeting Pale Moon, applicable to New Moon 28, too:

https://repo.palemoon.org/MoonchildProductions/Pale-Moon/commit/4f00b12

[VistaLover]

On 3/31/2021 at 2:16 AM, VistaLover said:

On 3/30/2021 at 10:58 AM, luweitest said:

So my bug report is still valid: https://github.com/JustOff/github-wc-polyfill/issues/21

Well, AFAIK, @JustOff only supports official Pale Moon, official Basilisk and SeaMonkey 2.53.x; he doesn't support pre-Quantum Mozilla Firefox (v52-56), nor any other Fx52ESR-based fork...
(snipped)
Imagine the case your wish has been granted by @JustOff and his extension installs out-of-the-box in Serpent 52.9.0;
(snipped)
The extension would have no issue installing in a 2018 build of Serpent 52 (on Firefox ESR 52.x.x, too), but obviously the GitHub experience there would be substandard... Do you think @JustOff is willing to deal with such scenarios?
(snipped)
... so, things aren't as clear-cut as initially imagined; the ball is now in @JustOff's court, so let's wait for his reaction... 

... And the man has spoken:

https://github.com/JustOff/github-wc-polyfill/issues/21#issuecomment-813060443

Quote

Sorry, but no, otherwise it will mislead users of the original Firefox,
where this extension doesn't fix the incorrect operation of GitHub.

... Didn't I tell you so?

[DanR20]

7 hours ago, VistaLover said:

Twitter related upstream change targeting Pale Moon, applicable to New Moon 28, too:

https://repo.palemoon.org/MoonchildProductions/Pale-Moon/commit/4f00b12

This just started with Serpent 52 and 55 in the last week or so. I don't know why Twitter rejects the most recent user string when it's with the Serpent versions but accepts it if you use an older one. Youtube does the same thing.

Good to see Moonchild is on the case but I suspect at some point these older versions will get the IE11 treatment regardless of what user string we give them.

[VistaLover]

On 3/28/2021 at 1:56 AM, gerwin said:

I have a small issue with the latest Palemoon/Newmoon 28, with language packs.
The dialog in Preferences->Content seemingly had some changes over the past months.
Since recently, it also has a "Media Formats" field at the bottom.
But all the available NL/Dutch language packs that I download are lacking these fields.
Therefore, that dialog page will appear entirely empty.

Inside the language pack, the file "content.dtd" should hold these translated fields.
I am perfectly fine tweaking "content.dtd" manually, like before, but I cannot do so
until I find an example showing the new field names.

For the duration JustOff was the head of the official Pale Moon localisation project, he would maintain his own langpack (LP) GitHub repository,

https://github.com/JustOff/pale-moon-localization/releases

and his Pre-release LPs would target PM's unstable channel, with which NM28 has/had the closest affinity...
Modifying the minVersion value inside the install.rdf file, to account for NM28's different versioning, would produce an installable and functioning langpack...

 This practice used to work up to a point in time (e.g. I know it worked till the end of May 2019, when NM28 was at v.28.6.0a1); but,"upstream" started making coding decisions that were deemed "unwanted" by the majority of members here; old code was kept by us, but removed by upstream (e.g. WebIDE inside devtools) and vice-versa, i.e. they introduced new code that was not adopted here...

 Whenever these code differences introduce string modifications (addition or removal), then the PM-targeting LP becomes incompatible with NM28 to a varying degree; slight modifications in parts of the browser you don't use often may stay unnoticed, but when major core strings have been altered, considerable breakage takes place, even to the point that the non en-US pack renders NM28 unable to launch with it; a "safety" mechanism then silently disables that LP and re-launches the browser in the default (en-US) locale...

  I wrote the above "summary" for the sake of those unfamiliar with NM's localisation scenarios; FWIW, roytam1, from the very start, said he would not provide himself LPs for his browsers, we, as fork users, were just lucky we could, up to a point, "freeload" the ones prepared for PM by MCP (and get all the hatred from them for doing so... ).

Our (roytam1's  ) source tree had already diverged significantly from upstream even before JustOff was ousted from the MCP localisation team, but lack of his "unstable" LPs currently means that a DIY person like you can't peek into them to find newly introduced strings there (that could be migrated to a NM28-specific LP); the sole source of PM localisation now are the LPs intended for its release channel, to be found:

https://addons.palemoon.org/language-packs/

with NL on https://addons.palemoon.org/releases/pm-langpack-nl/

Save as .xpi file and extract with 7-zip, then look inside for new strings not yet incorporated into your own NM28 NL-pack; you have to be well versed in the folder/file structure of the LP, if you have a NM28 NL pack that used to work in previous NM versions, you can "build" on top of that and go forward towards more recent releases...
You must use a file diff application (or a text editor) to inspect the string differences between the exact same files of the two LPs, so you can modify your DIY one accordingly (taking care to incorporate only the new strings needed by our fork, the PM file may contain other strings not compatible with NM).

 Indication of strings modification in code can be found also on roytam1's GitHub repo; whenever UXP and/or Pale Moon source files that have a path containing "*/locales/en-US/*" are being modified, this signals modification to the natively bundled en-US langpack; these modifications should be reflected (and translated into Dutch, where applicable) in your DIY NM28 langpack.

For instance, for the "Media Formats" strings that you cited, the relevant commit is

[Pale-Moon] Issue #1862 - Add media format controls in Preferences -> Content

from which you can see the newly introduced (English) strings in file

application/palemoon/locales/en-US/chrome/browser/preferences/content.dtd

by loading:

https://github.com/roytam1/UXP/commit/650abe2cb9eb02c14369a807a6225ebb053d0b17#diff-d3c90e964941daf05f84a5b5192bc0c94f6f629dcc424dd23e8f87cc766cd4f7

Many times, it is difficult to tell on which LP file to apply the string changes committed to source files, this ain't one of them :

<LP root>\browser\chrome\nl\locale\browser\preferences\content.dtd

In conclusion, the natively bundled en-US langpack is found split between NM28's two omni.ja files:

".\palemoon\browser\omni.ja\chrome\en-US\*"

".\palemoon\omni.ja\chrome\en-US\*"

(use 7-zip to access); ultimately, these are all the files you have to translate into Dutch and then package appropriately (consult an existing LP) to make a functional NM28  nl-langpack.xpi; it ain't easy, is it? But I am open for any automation process you happen to be aware of (this extends to the rest of this community here ) ...

Kind regards

Edited April 8, 2021 by VistaLover

[nicolaasjan]

3 hours ago, VistaLover said:

For the duration JustOff was the head of the official Pale Moon localisation project, he would maintain his own langpack (LP) GitHub repository,

https://github.com/JustOff/pale-moon-localization/releases

and his Pre-release LPs would target PM's unstable channel, with which NM28 has/had the closest affinity...
Modifying the minVersion value inside the install.rdf file, to account for NM28's different versioning, would produce an installable and functioning langpack...

 This practice used to work up to a point in time (e.g. I know it worked till the end of May 2019, when NM28 was at v.28.6.0a1); but,"upstream" started making coding decisions that were deemed "unwanted" by the majority of members here; old code was kept by us, but removed by upstream (e.g. WebIDE inside devtools) and vice-versa, i.e. they introduced new code that was not adopted here...

 Whenever these code differences introduce string modifications (addition or removal), then the PM-targeting LP becomes incompatible with NM28 to a varying degree; slight modifications in parts of the browser you don't use often may stay unnoticed, but when major core strings have been altered, considerable breakage takes place, even to the point that the non-en_US pack renders NM28 unable to launch with it; a "safety" mechanism then silently disables that LP and re-launches the browser in the default (en-US) locale...

  I wrote the above "summary" for the sake of those unfamiliar with NM's localisation scenarios; FWIW, roytam1, from the very start, said he would not provide himself LPs for his browsers, we, as fork users, were just lucky we could, up to a point, "freeload" the ones prepared for PM by MCP (and get all the hatred from them for doing so... ).

Our (roytam1's  ) source tree had already diverged significantly from upstream even before JustOff was ousted from the MCP localisation team, but lack of his "unstable" LPs currently means that a DIY person like you can't peek into them to find newly introduced strings there (that could be migrated to a NM28-specific LP); the sole source of PM localisation now are the LPs intended for its release channel, to be found:

https://addons.palemoon.org/language-packs/

with NL on https://addons.palemoon.org/releases/pm-langpack-nl/

Save as .xpi file and extract with 7-zip, then look inside for new strings not yet incorporated into your own NM28 NL-pack; you have to be well versed in the folder/file structure of the LP, if you have a NM28 NL pack that used to work in previous NM versions, you can "build" on top of that and go forward towards more recent releases...
You must use a file diff application (or a text editor) to inspect the string differences between the exact same files of the two LPs, so you can modify your DIY one accordingly (taking care to incorporate only the new strings needed by our fork, the PM file may contain other strings not compatible with NM).

 Indication of strings modification in code can be found also on roytam1's GitHub repo; whenever UXP and/or Pale Moon source files that have a path containing "*/locales/en-US/*" are being modified, this signals modification to the natively bundled en-US langpack; these modifications should be reflected (and translated into Dutch, where applicable) in your DIY NM28 langpack.

For instance, for the "Media Formats" strings that you cited, the relevant commit is

[Pale-Moon] Issue #1862 - Add media format controls in Preferences -> Content

from which you can see the newly introduced (English) strings in file

application/palemoon/locales/en-US/chrome/browser/preferences/content.dtd

by loading:

https://github.com/roytam1/UXP/commit/650abe2cb9eb02c14369a807a6225ebb053d0b17#diff-d3c90e964941daf05f84a5b5192bc0c94f6f629dcc424dd23e8f87cc766cd4f7

Many times, it is difficult to tell on which LP file to apply the string changes committed to source files, this ain't one of them :

<LP root>\browser\chrome\nl\locale\browser\preferences\content.dtd

In conclusion, the natively bundled en-US langpack is found split between NM28's two omni.ja files:

".\palemoon\browser\omni.ja\chrome\en-US\*"

".\palemoon\omni.ja\chrome\en-US\*"

(use 7-zip to access); ultimately, these are all the files you have to translate into Dutch and then package appropriately (consult an existing LP) to make a functional NM28  nl-langpack.xpi; it ain't easy, is it? But I am open for any automation process you happen to be aware of (this extends to the rest of this community here ) ...

Kind regards

I used the Dutch language pack, but I'm afraid the above method is a bit to complicated for me...

Doesn't matter to much though, because I can understand English quite well.

[gerwin]

14 hours ago, VistaLover said:

For the duration JustOff was the head of the official Pale Moon localisation project, he would maintain his own langpack (LP) GitHub repository,

https://github.com/JustOff/pale-moon-localization/releases

and his Pre-release LPs would target PM's unstable channel, with which NM28 has/had the closest affinity...

 

Thanks a lot! I will check if the information you provided enables me to adjust the language pack for latest NM28. If so, I will share a copy here.

Edited April 8, 2021 by gerwin
wrote PM28, but I meant NM28.

[luweitest]

Today I visited a page causing Serpent52 hang:

https://www.fiverr.com/categories/programming-tech/desktop-app-services/application-improvements

When Noscript enabled, it could load; after enabled javascript, or restarted in safe mode, the browser freezes, takes 50% CPU (dual core), increases memory occupation near 100%, and I have to kill it.

[roytam1]

Advance Notice: since there is no sufficient changes from upstream, there will be no UXP based build this week.

[XPerceniol]

Not having any issues with that site on ST52 with script enabled ?

[i430VX]

9 hours ago, luweitest said:

Today I visited a page causing Serpent52 hang:

https://www.fiverr.com/categories/programming-tech/desktop-app-services/application-improvements

When Noscript enabled, it could load; after enabled javascript, or restarted in safe mode, the browser freezes, takes 50% CPU (dual core), increases memory occupation near 100%, and I have to kill it.

Try using the UOC patch. For whatever reason FF-based browsers completely flip out when they are used on my ThinkPad's video card (mobility radeon x1300), and a lot of freezing was happening. However, the UOC patch resolved the issue for sure.

Edited April 9, 2021 by i430VX

[XPerceniol]

I'm not sure if its making any difference; but I have these prefs set to the following:

user_pref("javascript.options.asmjs", false);
user_pref("javascript.options.baselinejit", false);
user_pref("javascript.options.discardSystemSource", true);
user_pref("javascript.options.ion", false);
user_pref("javascript.options.jit_trustedprincipals", true);
user_pref("javascript.options.strict", true);
user_pref("javascript.options.wasm", false);
user_pref("javascript.options.wasm_baselinejit", true);

[Sampei.Nihira]

12 hours ago, luweitest said:

Today I visited a page causing Serpent52 hang:

https://www.fiverr.com/categories/programming-tech/desktop-app-services/application-improvements

When Noscript enabled, it could load; after enabled javascript, or restarted in safe mode, the browser freezes, takes 50% CPU (dual core), increases memory occupation near 100%, and I have to kill it.

No problem with NM28:

Edited April 9, 2021 by Sampei.Nihira