Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


roytam1

My build of New Moon (temp. name) a.k.a. Pale Moon for XP

Recommended Posts

6 minutes ago, Tamris said:

Upgraded to RC4 and NM still throws an error:

GxzzF0b.png

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 by roytam1

Share this post


Link to post
Share on other sites

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

multiprocess + APZ + hardware accelerstion = bug

7295f94fff699a872c4126d035af36a1.jpg

 

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 by grey_rat
  • Like 1

Share this post


Link to post
Share on other sites
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 :(:realmad:; 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! :no:

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 :angry:...

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 :yes:...

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... :angry:); 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... :dubbio:

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

@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 :angry:; this is why we here, the XP/Vista communities, have, thanks to you :wub:, 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 by VistaLover
  • Like 2

Share this post


Link to post
Share on other sites
8 hours ago, VistaLover said:

... Likewise here :(:realmad:; 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! :no:

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 :angry:...

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 :yes:...

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... :angry:); 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... :dubbio:

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

@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 :angry:; this is why we here, the XP/Vista communities, have, thanks to you :wub:, 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 by roytam1

Share this post


Link to post
Share on other sites

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 :rolleyes:; 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... ;):P

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...

  • Like 1

Share this post


Link to post
Share on other sites

just have a deeper look into PM's webRTC code, its module is not updated to fx52 level and javascript module fails when loading https://test.webrtc.org/ demo.

so I decided to disable it again.

EDIT: pm28 builds updated

Edited by roytam1
  • Like 2
  • Upvote 1

Share this post


Link to post
Share on other sites

All right now with the new pm28 build : ENU -> FR ok !

Thank you a lot +++

  • Like 1

Share this post


Link to post
Share on other sites

@roytam1 Thanks a lot, everything is back to normal again :). Also thanks to @VistaLover , his detailed post saved us (again).

Edited by Tamris
  • Like 1

Share this post


Link to post
Share on other sites
On 1/12/2019 at 3:14 AM, roytam1 said:

New build of basilisk/UXP for XP!

Test binary:
Win32 https://o.rths.cf/basilisk/basilisk52-g4.1.win32-git-20190112-f38edc94a-xpmod.7z

Something isn't right with this build. It's crashing randomly on opening a new tab. Nothing of the sort happens with v. 20181208, so it must be due to some change done recently. I imagined there'd be other reports about it, but since there are none, here's mine. Bug-hunting is on!

Share this post


Link to post
Share on other sites

https://www.seamonkey-project.org/releases/#langpacks
For 'RT' Borealis XP Browser, have been able to successfully install two language packs from the above URL. Specifically, the "English (British)" and "Spanish (Spain)" ones. I used tips from (users here) 'RT' and 'VISTALOVER' in order to modify the INSTALL.RDF file to get this accomplished.

They show (list) as installed in BOREALIS Browser here:
ADD ONS MANAGER (Menu: Tools, Add Ons Manager) for LANGUAGES (Tab).
But I am NOT able to 'activate' either of them.

(Added a few days later) ==>
https://msfn.org/board/topic/177125-my-build-of-new-moon-temp-name-aka-pale-moon-for-xp/?do=findComment&comment=1158936
Okay, I got QUALITY feedback from RT (URL above, THANKS!). Who supplied a successful manner to install the SM-2.49 LANGPACKS in an apparently 'minimal' acceptable manner. The MENU Headings looked GOOD overall, when I did the install of the SPANISH Language PACK into the BorXP Browser.

 

Edited by TechnoRelic

Share this post


Link to post
Share on other sites
On 1/9/2019 at 2:29 PM, VistaLover said:

Hi :) ; this is a well known and documented limitation of said extension:

https://github.com/JustOff/ca-archive#compatibility-and-installation =>

The author (@JustOff) is a member of the Moonchild dev team, this addon was primarily conceived to be installed in Pale Moon and/or Basilisk; ... the latter does not officially support e10s (nor have any tests for it been performed with multiprocess mode turned on...).

However, the same author appears to be somehow affiliated with the Waterfox browser project, they are they ones kindly providing hosting space/bandwidth for all legacy extensions catalogued inside CAA.

Current Waterfox ... comes with e10s turned ON by default, hence CAA issue #2 was submitted; the extension author came up, in v1.2.2, with a "dirty hack" to deal with e10s in Waterfox:

What this hack in effect does is, instead of generating the


Multi-process mode is not supported now,
please disable it and restart Waterfox

pop up notification, upon clicking CAA's toolbar icon, it spawns a second non-e10s Waterfox window, where CAA can function properly (i.e. Waterfox can interpret the caa: protocol).

I have inspected the "new" code inside linked commit and, after local experimentation, have found out that implementing the same "dirty hack" for multiprocess Basilisk/Serpent is as simple as substituting the string "Waterfox"

(this is in file bootstrap.js) with the string "Basilisk":


- if (e10s && Services.appinfo.name != "Waterfox") {
+ if (e10s && Services.appinfo.name != "Basilisk") {

Hope it works for you as it did for me :yes:

Well, over the weekend CAA updated itself to version 1.2.3, overwriting the change you suggested. I reapplied the change and of course it works again, but obviously will have to do that every time CAA gets updated ... oh, well ....

Share this post


Link to post
Share on other sites
On 1/11/2019 at 8:28 AM, dencorso said:

On Basilisk/UXP, when I go to Help => About, what I get is this:

about.png

Which file should I edit to change the night-blue background or to add art to it?  :unsure:

Reply to myself:
%PROGRAMFILES%\basilisk\browser\omni.ja\chrome\browser\content\branding\about-background.png      :P:angel
 

 

Share this post


Link to post
Share on other sites
On 1/12/2019 at 8:13 AM, Sampei.Nihira said:

I have disabled WebRTC again.

The reason is a decrease in privacy:

https://browserleaks.com/webrtc

Specifically, WebRTC leaks two bits of info that may compromise your privacy:

  1. Device ID hashes for your microphone & camera
  2. The IP address on your local network

#1 can be used for browser fingerprinting, allowing the likes of Google and Facebook to secretly track your online activities; luckily it's mostly a problem for Chromium-family browsers, not for Firefox-family browsers like Basilisk. The latter browsers randomize the "salt" used in the hash whenever the browser is started, so unless you leave your browser session running for weeks at a time, the ability of anyone to use #1 as a secret tracking cookie is limited.

#2 is more problematic though. It can reveal your "real" address behind a VPN, which could be used for censorship, or alert the authorities that you're accessing "banned" material. More commonly, it will reveal one of those non-routeable local IP addresses starting with 10. or 192.168 assigned by your (real or virtual) router. That's less worrisome, but if it doesn't change often, it too can be used in conjunction with your public IP for browser fingerprinting.

If you don't need/use WebRTC, the website linked above contains instructions for disabling it and preventing those info leaks. But what if you do use it?

One solution might be the WebRTC Control add-on. This adds a toolbar button that simply toggles WebRTC on or off, a la the popular Flash Disable add-on. So you can leave it off for normal browsing, but turn it on before going to a site that requires it.

Edit: Should have checked first. Couldn't install WebRTC Control linked above. All three versions download OK but Basilisk reports that they all appear to be corrupt. Must be a bad hash somewhere :( Try the "classic" version of Disable WebRTC instead.

I think a better solution would be an add-on with a white-list, which would enable WebRTC automatically, but only for sites like Discord and Skype. But I haven't yet found a Basilisk-compatible add-on that has such a white-list :(

Edited by Mathwiz
  • Like 3

Share this post


Link to post
Share on other sites

watch later button (lower right corner) is missing on youtube under PM28.

 

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×