My Browser Builds (Part 1)

[TechnoRelic]

@roytam1 <--

I was wondering as to how many downloads (installs) that you get
say PER WEEK of your 'RT' XP compatible Browsers (so, BK52XP, NM28XP, BorXP, etc).
So, wondering if that you have access to 'RT' SERVER 'Stats' for that and would share.

Added: 'RT' did REPLY in a message below and said -->
"Never have a look on it since this is just "private" build to myself, download count is irrelevant to me."

Okay, was just curious as to some kind of popularity measure on it, THANKS to reply.
Having GOOD performance here with the 'RT' BorXP Browser, THANKS !!!

Edited January 12, 2019 by TechnoRelic

[Flame.]

1 hour ago, roytam1 said:

that maybe hard, since my patches are totally untested on non-MSVC and/or non-Windows environment.

Dammit, I forgot about that MSVC part! Oh well... So much for my hopes for an easy unbinding from MS.

Btw, do you have any previous experience with GCC/Clang? Hopefully - with some positive outcome. :)

[roytam1]

1 hour ago, TechnoRelic said:

@roytam1 <--

I was wondering as to how many downloads (installs) that you get
say PER WEEK of your 'RT' XP compatible Browsers (so, BK52XP, NM28XP, BorXP, etc).
So, wondering if that you have access to 'RT' SERVER 'Stats' for that and would share.

never have a look on it since this is just "private" build to myself, download count is irrelevant to me.

[grey_rat]

On 1/3/2019 at 8:35 AM, caliber said:

All right. that works for me too I feel the ''hungry'' sites such as facebook and youtube run quite a bit smoother

however the processor fan makes much more noise as the CPU usage goes up to 60%

layers.async-pan-zoom.enabled - false , in xp it badly works and overloads the system.

[caliber]

boolean, integrer or string ?

FF52 is working perfect now beyond the 2GB of RAM.

although it drains a lot more RAM and it doesn't drop quickly as I'm geting tabs closed.

I'm still waiting a response to my other post as the multi process trick is no longer functional on PM28

 

[dencorso]

1 minute ago, caliber said:

boolean, integrer or string ?

Boolean. The default is true.

[Reino]

On 1/1/2019 at 2:36 PM, roytam1 said:

it uses javascript that PM27 unable to run:

If I'm correct, Github now also uses javascript that PM27 can't run. The preview feature while posting message for instance doesn't work anymore.
I have no experience with Baselisk, or any other alternative browser, but would they work?

[roytam1]

54 minutes ago, CoRoNe said:

If I'm correct, Github now also uses javascript that PM27 can't run. The preview feature while posting message for instance doesn't work anymore.
I have no experience with Baselisk, or any other alternative browser, but would they work?

uxp-based browsers are working at the moment

[TechnoRelic]

On 1/12/2019 at 9:26 AM, grey_rat said:

layers.async-pan-zoom.enabled - false , in xp it badly works and overloads the system.

https://www.ghacks.net/2015/07/28/scrolling-in-firefox-to-get-a-lot-better-thanks-to-apz/
I found the above URL related to this 'APZ' issue.

The part that seems to matter most in the URL above is this part -->
"Please note that APZ is only enabled if you run Firefox (Browser) with E10s enabled.
The preference that determines whether APZ is enabled or not is
'layers.async-pan-zoom.enabled' (in the 'about:config' settings)."

So, to DISABLE this under WinXP with an old 'single core' CPU would seem a good choice.
In the end, one can try DISABLE, then ENABLE, and see if any difference.
GOOD suggestion overall, THANKS to post your message here.

Two more added 'about:config' tweaks that were suggested this Thread are:
(1) canvas.poisondata ; TRUE (change to that)
(2) "To disable 'e10s/multiprocess' (CPU) -- Go to 'about:config' by typing it in your URL bar.
Search for 'browser.tabs.remote.autostart' using the search box on 'about:config' ...
There may be multiple (similar named) results. Set them ALL to FALSE and restart the Browser."
browser.tabs.remote.* ; FALSE

A certain 'RT' Browser may or may NOT have a 'setting' (listing) for these entries.

Edited January 13, 2019 by TechnoRelic

[Tamris]

On 1/12/2019 at 10:10 AM, Tamris said:

Seems language packs aren't compatible with newest NM yet again... running 28.3 rc3 polish language pack, and NM just throws an error and reverts back to default language after that.

Upgraded to RC4 and NM still throws an error:

[roytam1]

6 minutes ago, Tamris said:

Upgraded to RC4 and NM still throws an error:

so it seems that their Localization team doesn't translate webrtc-related strings.

so, should I keep --enable-webrtc switch on next PM28 build?

Edited January 13, 2019 by roytam1

[grey_rat]

I tested in Firefox 52.9 on Athlon 64x2, GF6100 and GTX260:

multiprocess + APZ + hardware accelerstion = bug

 

multiprocess + hardware accelerstion = sliding scrolling (the best for me)

multiprocess + APZ (+10% CPU loading, only without error) = multiprocess + APZ + hardware accelerstion

multiprocess (smooth scrolling, without +10% CPU loading) = multiprocess + APZ

Edited January 13, 2019 by grey_rat

[VistaLover]

On 1/12/2019 at 11:10 AM, Tamris said:

Seems language packs aren't compatible with newest NM yet again... running 28.3 rc3 polish language pack, and NM just throws an error and reverts back to default language after that.

On 1/12/2019 at 11:33 AM, Gargam said:

Idem with the last "fr.xpi" + [general.useragent.locale -> fr]
Sorry...

... Likewise here ; after updating to the latest New Moon 28 win32 build [Version: 28.3.0a1 (32-bit) (2019-01-11), buildID=20190111225658], the official Pale Moon Greek language pack (el.xpi, even latest version 28.3.0_RC4 released mere minutes ago) stopped working!

Inquisitive as I am, I went for some troubleshooting, what I eventually discovered is quite ominous for NM28 users who want to use localisation in their favourite browser...

@roytam1 I kindly ask you to pay close attention to what I'll be detailing below, it is of somewhat "technical" nature, so apologies to those not able to follow through...

========================================

Previous NM28 build details:
Package name: palemoon-28.3.0a1.win32-git-20190105-7fcb7f544-xpmod.7z
"about:" info: Version: 28.3.0a1 (32-bit) (2019-01-04)
buildID: 20190104234139

=> Language Packs WORK

Current NM28 build details:
Package name: palemoon-28.3.0a1.win32-git-20190112-f38edc94a-xpmod.7z
"about:" info: Version: 28.3.0a1 (32-bit) (2019-01-11)
buildID: 20190111225658

=> Language Packs DON'T WORK

Changelog on the official UXP repo between builds is described by:

Comparing 7fcb7f5...f38edc9

As you're hopefully able to see, no change has been committed by the Moonchild devs to files inside

application/palemoon/locales/en-US/*

so the breakage of Language Packs in New Moon 28 isn't caused by changes upstream; this, in itself, means there will be 0 chance of the official LPs becoming compatible with NM28 in the future ...

So the next logical conclusion is that language packs became (and shall remain) broken due to something you yourself commited;
so, taking a closer look:

On 1/12/2019 at 7:14 AM, roytam1 said:

My changes since my last build:
- update libaom to git rev a1615ed01a112432825f231a1fa47295cff127b4
- update NSS to rev c8f7602ce9e6 with nss339-vc2013.diff applied
- enabled webrtc build option (untested in pm28, seems working in preliminary test in bk52)

libaom/NSS changes seem inconspicuous, but it is --enable-webrtc in "Configure options" (about:buildconfig) that is the real culprit for the LPs breakage ...

Indeed, building with WebRTC API enabled introduces new strings inside the browser, strings that are absent in the official Pale Moon 28 (where WebRTC is not implemented/supported) and so are equally absent inside any language pack meant for PM28. And since I don't have at my disposal a relevant git changelog depicting the locale changes introduced by WebRTC, it is/was very difficult for me to pinpoint these string changes easily...

My era as a Firefox Nightly tester somehow helped me in this task; I first set out to extract and compose the default en-US locale as has been compiled in this latest NM28 build (relevant directories/files are to be found in: 

<installDir>/palemoon/browser/omni.ja!/chrome/en-US/locale/*
<installDir>/palemoon/omni.ja!/chrome/en-US/locale/*

) and then compare this en-US LP with my installed el.xpi one, for newly introduced strings/files; I may have missed some non-important changes, but the main string change causing the break is to be found inside:

el.xpi!/browser/chrome/el/locale/browser/browser.dtd

Two new lines should be added:

<!ENTITY webrtcIndicatorButton.label "Camera / Microphone Access">
<!ENTITY webrtcIndicatorButton.tooltip "Display sites you are currently sharing your camera or microphone with">

(and be translated into the language of choice, Greek in my case...).

Then again, enabling WebRTC in NM introduces a new system page called "about:webrtc" which comes with many new strings which have to be added and hopefully localised; the strings for that "about:" page should be found inside file:

el.xpi!/chrome/el/locale/el/global/aboutWebrtc.properties

The en-US version of file aboutWebrtc.properties has been uploaded to: 

http://s000.tinyupload.com/index.php?file_id=63793921022754074631

With above changes implemented, I finally got 28.3.0_RC4.el.xpi to install and work OK in latest NM28 (but with more than 2 hours spent overall on this feat... ); it is more than obvious to me that a non-techie NM28 user who wishes to have NM28 localised in his/her native tongue would not be up for that... 

========================================

@roytam1 The following constitutes my personal views on the subject, you are free to proceed as you please:

1. Should you continue to build NM28 in the future with "--enable-webrtc", it would put a permanent end to NM localisations; the browser would only be capable of being run in the default en-US locale, much like Basilisk/Serpent is (for which no LPs are available).

2. I know you meant well and wanted to cater for those NM28 users that want to use voice chat features (e.g. Web Skype, Facebook, Web Discord etc.) in their browser; after all, that was an issue (lack of webrtc support in NM) I myself pointed out in the Vista Discord thread and recently, again, in this very thread.

3. I have no use myself for Voice Chat in NM28, for all that matters I don't know if what you did here even works as intended: 

On 1/12/2019 at 7:14 AM, roytam1 said:

enabled webrtc build option (untested in pm28

(e.g. I think WebRTC also implies the download and use of "OpenH264 Video Codec provided by Cisco Systems, Inc.", doesn't it?)

4. Official Pale Moon has never supported WebRTC, they have their reasons - privacy also being one of them, as pointed out by @Sampei.Nihira, so their code is tailored/optimised to that decision; why then should New Moon, a Pale Moon fork, attempt to implement WebRTC?

5. FirefoxESR 52.9.0 as well as its official fork Basilisk52/UXP are perfectly capable of handling WebRTC, albeit with some user-agent spoofing to ease up those sites insisting on NT 6.1+ and Google Chrome as browser ; this is why we here, the XP/Vista communities, have, thanks to you , an alternative browser choice, Serpent 52.9.0, to use when NM falls short; if it was upon me to decide, I would simply point voice chat users to Serpent (as I already have), than break localisation for New Moon (by enabling an unsupported feature there)...

6. Ultimately, it may come down to numbers; if there's an excess of NM28 users who prefer WebRTC (provided your latest "hack" works) compared to those who need their browser localised, then I guess the majority should prevail; in that case, may I kindly ask you continue to provide NM28 builds without the WebRTC API for those of us with no use for it but who still prefer the browser GUI localised?

Thanks for your time reading this long post, thanks again for your forks!

EDIT: When I started writing this,

https://msfn.org/board/topic/177125-my-build-of-new-moon-temp-name-aka-pale-moon-for-xp/?do=findComment&amp;comment=1158755

and

https://msfn.org/board/topic/177125-my-build-of-new-moon-temp-name-aka-pale-moon-for-xp/?do=findComment&amp;comment=1158756

had not been posted yet; I had to stop writing mid-way and was not notified (by e-mail) of them being posted; when I resumed and eventually finished writing, I just clicked Submit, oblivious to their existence 

 

Edited January 13, 2019 by VistaLover

[roytam1]

8 hours ago, VistaLover said:

... Likewise here ; after updating to the latest New Moon 28 win32 build [Version: 28.3.0a1 (32-bit) (2019-01-11), buildID=20190111225658], the official Pale Moon Greek language pack (el.xpi, even latest version 28.3.0_RC4 released mere minutes ago) stopped working!

Inquisitive as I am, I went for some troubleshooting, what I eventually discovered is quite ominous for NM28 users who want to use localisation in their favourite browser...

@roytam1 I kindly ask you to pay close attention to what I'll be detailing below, it is of somewhat "technical" nature, so apologies to those not able to follow through...

========================================

Previous NM28 build details:
Package name: palemoon-28.3.0a1.win32-git-20190105-7fcb7f544-xpmod.7z
"about:" info: Version: 28.3.0a1 (32-bit) (2019-01-04)
buildID: 20190104234139

=> Language Packs WORK

Current NM28 build details:
Package name: palemoon-28.3.0a1.win32-git-20190112-f38edc94a-xpmod.7z
"about:" info: Version: 28.3.0a1 (32-bit) (2019-01-11)
buildID: 20190111225658

=> Language Packs DON'T WORK

Changelog on the official UXP repo between builds is described by:

Comparing 7fcb7f5...f38edc9

As you're hopefully able to see, no change has been committed by the Moonchild devs to files inside

application/palemoon/locales/en-US/*

so the breakage of Language Packs in New Moon 28 isn't caused by changes upstream; this, in itself, means there will be 0 chance of the official LPs becoming compatible with NM28 in the future ...

So the next logical conclusion is that language packs became (and shall remain) broken due to something you yourself commited;
so, taking a closer look:

libaom/NSS changes seem inconspicuous, but it is --enable-webrtc in "Configure options" (about:buildconfig) that is the real culprit for the LPs breakage ...

Indeed, building with WebRTC API enabled introduces new strings inside the browser, strings that are absent in the official Pale Moon 28 (where WebRTC is not implemented/supported) and so are equally absent inside any language pack meant for PM28. And since I don't have at my disposal a relevant git changelog depicting the locale changes introduced by WebRTC, it is/was very difficult for me to pinpoint these string changes easily...

My era as a Firefox Nightly tester somehow helped me in this task; I first set out to extract and compose the default en-US locale as has been compiled in this latest NM28 build (relevant directories/files are to be found in: 

<installDir>/palemoon/browser/omni.ja!/chrome/en-US/locale/*
<installDir>/palemoon/omni.ja!/chrome/en-US/locale/*

) and then compare this en-US LP with my installed el.xpi one, for newly introduced strings/files; I may have missed some non-important changes, but the main string change causing the break is to be found inside:

el.xpi!/browser/chrome/el/locale/browser/browser.dtd

Two new lines should be added:

<!ENTITY webrtcIndicatorButton.label "Camera / Microphone Access">
<!ENTITY webrtcIndicatorButton.tooltip "Display sites you are currently sharing your camera or microphone with">

(and be translated into the language of choice, Greek in my case...).

Then again, enabling WebRTC in NM introduces a new system page called "about:webrtc" which comes with many new strings which have to be added and hopefully localised; the strings for that "about:" page should be found inside file:

el.xpi!/chrome/el/locale/el/global/aboutWebrtc.properties

The en-US version of file aboutWebrtc.properties has been uploaded to: 

http://s000.tinyupload.com/index.php?file_id=63793921022754074631

With above changes implemented, I finally got 28.3.0_RC4.el.xpi to install and work OK in latest NM28 (but with more than 2 hours spent overall on this feat... ); it is more than obvious to me that a non-techie NM28 user who wishes to have NM28 localised in his/her native tongue would not be up for that... 

========================================

@roytam1 The following constitutes my personal views on the subject, you are free to proceed as you please:

1. Should you continue to build NM28 in the future with "--enable-webrtc", it would put a permanent end to NM localisations; the browser would only be capable of being run in the default en-US locale, much like Basilisk/Serpent is (for which no LPs are available).

2. I know you meant well and wanted to cater for those NM28 users that want to use voice chat features (e.g. Web Skype, Facebook, Web Discord etc.) in their browser; after all, that was an issue (lack of webrtc support in NM) I myself pointed out in the Vista Discord thread and recently, again, in this very thread.

3. I have no use myself for Voice Chat in NM28, for all that matters I don't know if what you did here even works as intended: 

(e.g. I think WebRTC also implies the download and use of "OpenH264 Video Codec provided by Cisco Systems, Inc.", doesn't it?)

4. Official Pale Moon has never supported WebRTC, they have their reasons - privacy also being one of them, as pointed out by @Sampei.Nihira, so their code is tailored/optimised to that decision; why then should New Moon, a Pale Moon fork, attempt to implement WebRTC?

5. FirefoxESR 52.9.0 as well as its official fork Basilisk52/UXP are perfectly capable of handling WebRTC, albeit with some user-agent spoofing to ease up those sites insisting on NT 6.1+ and Google Chrome as browser ; this is why we here, the XP/Vista communities, have, thanks to you , an alternative browser choice, Serpent 52.9.0, to use when NM falls short; if it was upon me to decide, I would simply point voice chat users to Serpent (as I already have), than break localisation for New Moon (by enabling an unsupported feature there)...

6. Ultimately, it may come down to numbers; if there's an excess of NM28 users who prefer WebRTC (provided your latest "hack" works) compared to those who need their browser localised, then I guess the majority should prevail; in that case, may I kindly ask you continue to provide NM28 builds without the WebRTC API for those of us with no use for it but who still prefer the browser GUI localised?

Thanks for your time reading this long post, thanks again for your forks!

EDIT: When I started writing this,

https://msfn.org/board/topic/177125-my-build-of-new-moon-temp-name-aka-pale-moon-for-xp/?do=findComment&amp;comment=1158755

and

https://msfn.org/board/topic/177125-my-build-of-new-moon-temp-name-aka-pale-moon-for-xp/?do=findComment&amp;comment=1158756

had not been posted yet; I had to stop writing mid-way and was not notified (by e-mail) of them being posted; when I resumed and eventually finished writing, I just clicked Submit, oblivious to their existence 

 

and there is 3rd option: make that button non-translatable and keep it in english, while language pack is still applicable to others, just see if you are satisfied having a non-translated button with webrtc-enabled in PM28. (don't know if about:webrtc is untranslated(missing aboutWebrtc.properties) will break browser or not)

and also 4th option: bug their localization team to translate that button.

Edited January 14, 2019 by roytam1

[VistaLover]

With all due respect...

23 minutes ago, roytam1 said:

make that button non-translatable and keep it in english, while language pack is still applicable to others, just see if you are satisfied having a non-translated button with webrtc-enabled in PM28.

I am afraid you fail to see the bigger issue; the problem here isn't about me (or two Polish NM28 users or a French guy, etc.) wanting to see the WebRTC button translated into my (their) native language; it can, of course, be in English, I couldn't care less if it was in Korean for all I know, as I wouldn't be using it myself...

The problem is that already available PM28 official language packs (look here, it's 39 of them) cannot be used any more with your NM28 fork; for the browser to simply start in a localised GUI, the two lines (be it in English, I don't mind) cited in my previous post have to be inserted manually in every one of them, in order to become again functional when installed in NM28; who is going to provide those NM28 (half-)compatible language packs? Mind you, that process should be repeated every once the packs get updated upstream...

47 minutes ago, roytam1 said:

(don't know if about:webrtc is untranslated (missing aboutWebrtc.properties) will break browser or not)

If a language pack is missing the aboutWebrtc.properties file, then it's not fatal as the missing lines in browser.dtd (NM28 will launch localised), but when such a LP user navigates to "about:webrtc", he/she will be met by a blank page; as said, I don't use WebRTC, but from a quick look at that page I see it contains useful configuration/functionality...

56 minutes ago, roytam1 said:

bug their localization team to translate that button.

I have no inclination (nor legitimate right, someone would argue) to contact their l10n team; for starters, I (and other XP/Vista users here) am not using the official product, i.e. Pale Moon 28, for which uniquely the language packs are intended to work with, but a fork (which we know how much they frown upon); let alone a fork which has just implemented a feature unsupported by design in the original product... "translate that button"?... what button, may I ask? They will never implement WebRTC in Pale Moon, their default en-US locale code simply has no strings related to webrtc, nothing for them to translate; or are you (or anyone else for that matter) under the impression that somehow we could beg and convince @JustOff (head of l10n team) to compile WebRTC enabled PM28 test builds (against Moonchild's wishes) and generate applicable language packs, just for the sake of international NM28 users, here in the MSFN forums (and continue to do so with every upstream string change)? With respect, this expectation is absurd, a folly even... 

As I see it, it is indeed a bonus that we are (were) able to use official PM28 LPs in NM28; after all, official LPs contain the official branding , I bet both Moonchild and Matt A. Tobin will go ballistic if they become aware... So NO, I see no reason to contact any of the Moonchild Productions persons with regards to this; it will only make matters worse for us...

To conclude, it's not about me; I know my way around LPs and have produced a private, working, Greek Language Pack, that mitigates the WebRTC inflicted changes; I even transplanted to it a fully translated (in Greek) copy of file aboutWebrtc.properties that I extracted from the Greek LP for FirefoxESR 52.9.0; I think I can move forward merrily, no matter what the decision taken about the future direction of NM28...

Still, nothing is foolproof: my installed modded Greek LP informs me that an update to (official) version 28.3.0 is available ; now, I shall have to be very cautious not to install it inadvertently, because - guess what? - if I do, my default Vista browser will revert to its en-US GUI...

Frankly, I don't have anything additional to contribute to this discussion; what I had to say is best summed up in my previous relevant post; it would be prudent, though, that some additional views/opinions of users here be voiced before the fate of the webrtc-in-NM28 feature is finally cast...

As ever, best regards and many thanks to the maintainer...