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 fork targetting XP

Recommended Posts

On 6/15/2019 at 5:58 PM, roytam1 said:

you still can fork boc's repo and make changes on it. once modifications are completed you can tell me the url of your fork/branch so I can get a diff and apply it to my tree.

I've now done this: https://github.com/Mathwi/binoc-central

At this point I've only touched MailNews. Moved two prefs to branding so I could split official & unofficial builds, and changed the unofficial prefs as follows:

  • app.releaseNotesURL changed, in order to redirect Help / Release Notes to @roytam1's blog.
  • app.support.baseURL changed, in order to redirect Help / Help Contents (as well as the "support website" link found in Help / Troubleshooting Info) to a placeholder page @roytam1 set up, vs. BinOC's IRC.

Both changes are consistent with previous changes to NM and Serpent.

Yet to do: change the link "The Open Source Community" in the Help / About MailNews pop-up window, which currently points to http://binaryoutcast.com/. I could use some help locating the source of this link.

  • Like 1
  • Upvote 1

Share this post


Link to post
Share on other sites

1 hour ago, VistaLover said:

... Wouldn't all this new hardware cost a fortune? :whistle:

yes it does, but since my current rig is already 7 years old and it deserves an update.

  • Like 1

Share this post


Link to post
Share on other sites
17 hours ago, Mathwiz said:

Yet to do: change the link "The Open Source Community" in the Help / About MailNews pop-up window, which currently points to http://binaryoutcast.com/ . I could use some help locating the source of this link.

In the original repository, you probably mean the following code in the "about" box:

https://github.com/binaryoutcast/binoc-central/blob/c6c62f93930f4809de4b63cd91ef83412e7e299f/projects/mail/base/content/aboutDialog.xul#L57-L59

          <description class="text-blurb" id="communityDesc">
            &community.start2;<label class="text-link" onclick="openURL('http://binaryoutcast.com/');" oncommand="openUILink(this.getAttribute('href'), event);">&community.mozillaLink;</label>&community.middle2;
          </description>

Disclaimer: I'm not using MailNews myself... :rolleyes:

 

  • Like 2

Share this post


Link to post
Share on other sites
33 minutes ago, Jody Thornton said:

@VistaLover would you happen to be Vistaar over at the DM Vista Forums?  :)

... No! :no:

  • Like 1

Share this post


Link to post
Share on other sites

Some potentially new trouble over the horizon, caused by upstream changeset below:

https://github.com/MoonchildProductions/UXP/commit/f7f7224dedd63809fbf5532b7ac843cea22d9499

As most of you know, official Basilisk no longer supports Web Extensions, because what limited support there was (somewhat inferior to the one present in Firefox ESR 52.9.x) was decided by MCP to be removed, purportedly for "security" reasons - that change was reverted by @roytam1 and so WE support in Serpent 52.9.0 has been kept.

With WE support removed, MCP proceeded to also remove some latent e10s code still present in platform (UXP) level; this was UXP issue #1130, resolved by upstream commit git-19c0f5e

Because "we" have kept WE support, that change was also reverted in Serpent 52, so that one can still force-enable e10s in that fork...

At the time, I commented that perhaps the upstream change was favourable for implementation on New Moon 28 alone, because if one force-enables e10s on NM28, one will end up with an unresponsive browser and/or profile corruption (e.g. previous session is mangled :angry:); this is because, and that was stated previously, PM28/NM28 as applications have no code at all to support multiprocess (e10s); Serpent 52, OTOH, does have such support, so force-enabling e10s there doesn't cause havoc... But, since the upstream change was at platform level, I was told it wouldn't be feasible to selectively implement it on NM28 but revert it on Serpent 52, so I didn't pursue this further...

Having thought about it in a later instance, this is still feasible, perhaps not very practical:

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

has two branches currently: 1) master, which in essence mirrors the upstream UXP master branch and 2) custom, which encompasses all @roytam1's custom changes and it's used to build both St52 and NM28, probably the Binary Outcast forks, too...

One could create a third branch, e.g. NM-custom, initially as a custom branch clone, implement the upstream changes (19c0f5e + f7f7224) just there and use this branch to compile NM28, while the original custom branch can continue to be used for Serpent 52 compilations!

The latest MCP change modifies two language pack files:

toolkit/locales/en-US/chrome/global/aboutSupport.dtd

https://github.com/MoonchildProductions/UXP/commit/f7f7224dedd63809fbf5532b7ac843cea22d9499#diff-3f6259650a01247c84ac14224308b455

and toolkit/locales/en-US/chrome/global/aboutSupport.properties

https://github.com/MoonchildProductions/UXP/commit/f7f7224dedd63809fbf5532b7ac843cea22d9499#diff-7e2b1f36d16b447ed465c9f234751864

Since UXP/custom still supports force-enabling e10s, come next Saturday, the platform-wide upstream change must be reverted by @roytam1, because if not, Serpent users who have force-enabled e10s there won't have an easy indication it's being active, apart from chasing basilisk.exe processes in Task Manager - and there's an additional possibility the about:support tab in St52 won't load if the change isn't reverted (?).. 

If reverted, then future official Pale Moon language packs will cease to work with future New Moon 28 builds (because the official localisation team will soon remove those localised strings and about:support tab will get broken in NM28 with an official LP installed); I'm sure many non-English users of NM28 (I can think of several Polish speakers, one or two Italian speakers etc.) wouldn't want that to happen ;) ...

So, what will the course of action be? We've reached that place before in the past, when some people asked that WebRTC support be enabled in NM28 (it's non-existent in PM28), and in the end language pack users "won" (for lack of a better word, it was not a "contest" as such...); what will it be now? :dubbio:Mind you, this hurdle can be circumvented by the UXP 3-branch "method" I detailed above... :whistle:

 

Edited by VistaLover

Share this post


Link to post
Share on other sites

Ironically the above was one of the changes suggested by Feodor2:

Quote

Also what about multiprocess windows int [sic] the about:support?

... so I guess despite the negativity expressed at the time, MCP decided to go with it and remove that row of info from the about:support page.

This latest issue doesn't sound too serious to me. If @roytam1 incorporates the latest change, I don't see it preventing the about:support page from working, even if e10s is forced on. Should be tested, of course, but it looks to me like that row of info will simply disappear from NM 28's and Serpent 52's about:support pages, so language pack compatibility between his builds and the official builds will be maintained. It does have the drawback that, on Serpent, the about:support page will no longer provide an easy way to tell whether e10s is functioning, but I for one could live with that.

Nevertheless, I like the suggestion of having separate "custom" branches for NM and Serpent. Actually, it would be possible to just compile NM 28 from the "master" branch, but that would lose the branding customization we recently did for NM, so it's probably best to have two "custom" branches.

Share this post


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

platform-wide upstream change must be reverted by @roytam1

yes but for that rev is not the case that I need to revert, since this rev affects about:support only and not the actual e10s code.

Share this post


Link to post
Share on other sites
10 hours ago, Mathwiz said:

Nevertheless, I like the suggestion of having separate "custom" branches for NM and Serpent.

Thanks for your vote of confidence :) ; IMHO, that way we can safely stay clear from any future conflicts between respective official applications and "our" forks...

10 hours ago, Mathwiz said:

Actually, it would be possible to just compile NM 28 from the "master" branch

I think not, because, as I said, roytam1/UXP/master is practically a mirror of MoonchildProductions/UXP/master, as such it doesn't contain the patches for XP/Vista compatibility, nor any of the other patches currently present in the custom branch...

10 hours ago, roytam1 said:

yes but for that rev is not the case that I need to revert, since this rev affects about:support only and not the actual e10s code.

So that means you'll merge

https://github.com/MoonchildProductions/UXP/commit/f7f7224

into roytam1/UXP/custom, with the side-effect being:

11 hours ago, Mathwiz said:

It does have the drawback that, on Serpent, the about:support page will no longer provide an easy way to tell whether e10s is functioning

I'm not using e10s in Serpent 52 myself, so I won't be affected, but that change should be made perfectly clear to those that do...

Regards

Share this post


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

So that means you'll merge

https://github.com/MoonchildProductions/UXP/commit/f7f7224

into roytam1/UXP/custom, with the side-effect being:

22 hours ago, Mathwiz said:

It does have the drawback that, on Serpent, the about:support page will no longer provide an easy way to tell whether e10s is functioning

partly, I think I may modify it to be non-translatable to keep compatibility to official language packs.

Share this post


Link to post
Share on other sites
2 hours ago, Jody Thornton said:

@Roytam I wouldn't think your New Moon v27 builds would be affected by this at all, no?

https://www.ghacks.net/2019/07/11/pale-moons-archive-server-hacked-and-used-to-spread-malware/

 

not affected. their server occurred a break-and-enter incident and those archives were injected with backdoor.

since my server can't upload/update archives from internet and this should be fine.

  • Like 5
  • Upvote 2

Share this post


Link to post
Share on other sites
3 hours ago, Jody Thornton said:

I wouldn't think your New Moon v27 builds would be affected by this at all, no?

NM27 binaries, as well as other browser binaries offered by @roytam1, are hosted on a completely different VPS infrastructure and on a (naturally) different hostname, o.rths.cf; unless the same hacker team that targeted archive.palemoon.org, for their own perverse agenda, also targeted o.rths.cf, we should be OK... 

This latest security breach, which managed to remain undetected for more than 18 months, demonstrates that:

1. Server administrators/owners must always stay alert for such an eventuality, keeping an eye their hosted files remain intact.

2. Users accessing servers with the prospect of downloading files must always exercise due precautionary practices (e.g. scanning files with updated and reputable AV solutions) ...

Official PM forum entries:

https://forum.palemoon.org/viewtopic.php?f=1&t=22528

https://forum.palemoon.org/viewtopic.php?f=17&t=22526

https://forum.palemoon.org/viewtopic.php?f=1&p=170828#p170828

Edited by VistaLover

Share this post


Link to post
Share on other sites
12 minutes ago, roytam1 said:

since my server can't upload/update archives from internet

If I may ask, how do you upload updated binaries there every Saturday, if not by an internet connection? Or, did that mean (only) you have physical access to the server and you upload files locally (e.g. via USB external drives)?

Also, from a forum exchange some months ago, when the previous hostname (o.rthost.cf) was revoked, it emerged that you were/are employing a free VPS service; so, aren't you in fact dependent on the security measures enforced by this VPS provider?

I am not being paranoid here, just inquisitive... ;) :)

Share this post


Link to post
Share on other sites
1 hour ago, VistaLover said:

it emerged that you were/are employing a free VPS service

not VPS, just free domain name provided by freenom. they can always close any free domain without reason and I always have several free domain names for my tasks.

 

1 hour ago, VistaLover said:

if not by an internet connection?

by intranet :)

  • Upvote 1

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...