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

Posted (edited)
4 hours ago, DanR20 said:

Thanks, I missed that in the changelog.

Curious, what exactly were they "cleaning up"? Container tabs worked good and were useful. It wouldn't be a problem if the addon could replace them but it isn't functional and I tried all their versions. So I guess for container tabs I'll have to use 52esr.

To be fair, they did this in part for speed:

Quote

So far there have been no side affects (sic) other than a noticeable speed increase in tab performance, and cookies being visible for background thumbnails which were previously hidden.

... but I suspect they were a bit overconfident in the Multifox add-on when they made this decision:

Quote

As Contextual Identity is already disabled by default in app/profile's js and can likely be replaced with an addon (MultiFox et. all (sic)) at a later date we can probably remove this code.

Key word being "likely." If someone had bothered to test MultiFox, they might have realized it's not quite ready to replace what was removed.

3 hours ago, DanR20 said:

The other option is private windows, that is until that gets cleaned up too. I'm afraid if they keep doing that there will be nothing left of the browser and no reason to use it.

This isn't the first time that MCP has gotten overzealous (IMO) in removing useful functionality. It wasn't all that long ago that they removed all WE APIs, thus forcing most users to either dump all their WE add-ons (with Basilisk) or all their legacy add-ons (with Firefox). Luckily for us @roytam1 reverted that change in Serpent.

This time, it looks like Matt A. Tobin was on the side of keeping the functionality, at least in Basilisk:

Quote

@mattatobin mentioned we may still want to keep Contextual Identity in Basilisk since it is the toolkit demo application.

The big difference this time is that fewer folks knew container tabs even existed. I didn't know about them either until you mentioned them and the about:config prefs that enable them, but now that I see what they do, I can see their utility and am also reluctant to update.

Edited by Mathwiz

Share this post


Link to post
Share on other sites

That's a very nice addon by Infocatcher, thanks VL for telling me about it.

It's not quite the same as container tabs, it's basically a private window in a tab instead but it's so much nicer and convenient than opening it up in a window. Lots of options too; I like being able to easily toggle between a regular tab and a private one. Definitely a keeper.

Container tabs have a different function in the way they keep cookies and history separated between the tabs. Maybe Roy can bring that back too the way he did webextensions? Don't want to push our luck on this but I wish the main guys would stop removing useful features, you'd think they were Mozilla or something.

 

  • Like 1

Share this post


Link to post
Share on other sites
53 minutes ago, Mathwiz said:

The big difference this time is that fewer folks knew container tabs even existed. I didn't know about them either until you mentioned them and the about:config prefs that enable them, but now that I see what they do, I can see their utility and am also reluctant to update.

They're useful if you want to sign into different accounts at the same site at the same time, or to prevent possible tracking. I only recently started making use of them myself and hate to see them removed so unceremoniously but like you said, many probably don't even know the feature exists.

Share this post


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

Container tabs were removed from official Basilisk 52.9.2019.xx.xx upstream; this "code cleanup" was tracked in UXP issue #756 and finally implemented via UXP PR #834; the latest UXP changelog posted by @roytam1 here does have that code merged, 

so yes, the upstream changes made it to latest Serpent 52.9.0 ;) (packages "basilisk52-g4.1.win**-git-20190330-843e4ceff-xpmod.7z); I bet Roy goes into the trouble of posting the official UXP changelog so that people can inform themselves... :P

if there is a need of this, I can restore it by reverting them.

Share this post


Link to post
Share on other sites
19 hours ago, DanR20 said:

All one has to do is look at Quantum to know how true that statement is. It's one of the main reasons for using forks like basilisk in the first place.

Quantum is great IMO - fast, beautiful. The way Chrome should be, actuallly (which is getting slower and slower these days).

Share this post


Link to post
Share on other sites
Posted (edited)

Guys, SOS, need your help :(

GitHub stopped working completely under Win XP. Tried New Moon 27, New Moon 28 and Firefox 52 ESR - nothing helps. In Firefox 52 I still can see some errors in Console (and in NM too), but as of Chrome 45 - the Console is absolutely clean. It just does not work. I mean I can submit a post (it seems it is an old plain <form>), but no button (quotation, formatting, edit or delete submitted post) will work.

Can you confirm the bug? Will updating to latest release (I have the one before the latest) solve the problem?

UPD: investigated further. It seems their server is blocking the scripts from sending them to older browsers. This is what Firefox 52 ESR is trying to load:

https://github.githubassets.com/node_modules/details-element-polyfill/dist/details-element-polyfill.js

And this is what it gets:

Not Found

UPD: It seems I found what's happening. I don't know why the Sources panel displays so many script (which it cannot load), but the problem is that with older browsers (Firefox 56 included) GitHub returns some fallback JS (unsupported-bootstrap.js), which surely doesn't do much and nothing is working. SO I downloaded the User-Agent switch extension for my Firefox 52... And then I got an error in Console, saying that the page's Content-Security-Policy didn't allow the spoofing code from the extension to be injected into the page. LOL :D

Edited by Alex654

Share this post


Link to post
Share on other sites
Posted (edited)
8 hours ago, Alex654 said:

GitHub stopped working completely under Win XP. Tried New Moon 27, New Moon 28 and Firefox 52 ESR - nothing helps.

For starters, forget completely New Moon 27/Tycho; the platform is just too old (even with the rmottola/Arctic-Fox third party patches) to support the most modern JS/CSS code GitHub are employing...

Since a few weeks ago, Mozilla 52 platform and its forks seems to be the bare minimum to support GitHub, but NOT out-of-the-box; GitHub's support policy is to support 1) current Firefox stable release (66.0.2) and 2) current FirefoxESR release (60.x.x); on older detected (via UA sniffing) Firefox versions, they're just sending unsupported code :realmad:

It just so happens that the JS/CSS code they send for FxESR 60 can still be handled adequately by FxESR 52 and the UXP platform browsers (official Pale Moon 28 - release & unstable - and Basilisk 52, and forks like New Moon 28.5.0a1, MyPal 28.4.1, Serpent 52.9.0 and Centaury 0.0.4; but in these browsers you'd have to use a SSUAO for GitHub to spoof FxESR 60:

general.useragent.override.github.com;Mozilla/5.0 (Windows NT 6.1; rv:60.0) Gecko/20100101 Firefox/60.0

In the case of Serpent 52.9.0, I find a simpler SSUAO also works:

general.useragent.override.github.com;Mozilla/5.0 (Windows NT 6.1; rv:52.0) Goanna/4.1 Basilisk/52.9.0

All UXP browsers support SSUAO natively; FxESR 52 has that feature disabled by design and you'd have to use specialised extension(s) or patch the browser yourself; see the discussion starting here ;)

What is indeed ominous is the fact FirefoxESR 60 is currently at version 60.6.1; when it reaches v60.8.x in 3-4 months, it'll be EoS and thus become unsupported by GitHub; then their ESR support will switch to v67; it is questionable whether the code they'll be serving to that would still be backwards compatible (via a SSUAO hack) with ESR52/UXP; I trust the Moonchild Productions devs would do their best to restore GitHub support in their UXP platform...

PS: SSUAO = Site-Specific-User-Agent-Override

Edited by VistaLover

Share this post


Link to post
Share on other sites
Posted (edited)
1 hour ago, VistaLover said:

For starters, forget completely New Moon 27/Tycho; the platform is just too old (even with the rmottola/Arctic-Fox third party patches) to support the most modern JS/CSS code GitHub are employing...

But as I read on this forum, GitHub actually was working in New Moon 27 as of September-October 2018 (I visit this thread from time to time). What are the new features that are not supported and why GitHub had to deploy them, don't you know?

Quote

FxESR 52 has that feature disabled by design and you'd have to use specialised extension(s) or patch the browser yourself

Thanks for clarification about UA override (in about:config I saw option to override the UA on per site basis, and it was even enabled by default for whatever reason); as for the extensions, I already have tried one, the result is described above - it failed to deal with the CSP directive.

Anyway, I did the following steps on my Chrome 45 (sorry for offtopic, I know this forum is not for Chrome/Chromium discussion, but maybe it can help someone):

  1. Declared a User-Agent header override in the Resource Override extension (maybe there are similar extensions available for Firefox/Pale Moon)
  2. That allowed to receive 2 JS files from GitHub (for modern browsers), one of them definitely contains new unsupported language features (spread operator in objects, it is part of ES2018 and even Babel JS does not transpile it to ES5 yet, unfortunately).
  3. Put the files in Babel on their site and edited the results manually in order to make the script fully ES5-compliant
  4. Made a rule to modify/remove CSP header in order to make the browser allow these modified scripts to be injected.
  5. And here I got STUCK. With other sites before it would be OK, and the file got actually injected. This time (how is it even possible?) the error text changes (from saying that CSP directive "..." does not allow the resource to load to saying that Origin null is not allowed - and that is despite the fact I allowed data: scheme!), but my modified scripts still do not load. Hence the site stays unusable as it was before.

Someone who knows CSP and Chrome behaviour better, please help me to fix this.

Or maybe suggest the extension that allows to inject scripts and modify arbitrary headers for Firefox 52 / New Moon 27-28.

As you see, version 27 is really not a big problem; it's just the ... operator in 2 places in 1 of 2 scriipts that causes the script to crash when UA is spoofed in New Moon 27/28 (and on Chrome 45 also another JS constructions break the browser, because it does not support ES6 at all, but it is really easy to fix).

Edited by Alex654

Share this post


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

Quantum is great IMO - fast, beautiful. The way Chrome should be, actuallly (which is getting slower and slower these days).

That's a matter of opinion and I'll grant you 60esr isn't bad, I just installed infocatcher's Private Tab addon on it and it works great.  But does it get things done in comparison to the older legacy versions: no because so many other useful legacy addons are non-functional.

Share this post


Link to post
Share on other sites
Posted (edited)
7 hours ago, Alex654 said:

GitHub actually was working in New Moon 27 as of September-October 2018

FxESR 52.9.0 reached EoS in Sept 6th 2018, so for a short while during Sep 2018 (and possibly during the start of Oct 2018) MozillaESR 52 platform was still natively compatible with GitHub; the code GitHub served at the time to FxESR 52 was, at its greater part, backwards compatible with the Tycho platform (fork of MozillaESR 38), so, yes, GitHub was (mostly) working in NM27 back then; especially as @roytam1 went the extra mile to patch, after my report, the non-working "preview tab" under the "submit-a-comment" section...

But as time progressed, GitHub moved on to officially targeting FxESR 60, sending back updated code, that was no more backwards compatible with Tycho (NM27); it happens to still be compatible with MozillaESR 52 + UXP, that's why browsers built on these platforms do work when spoofed to FxESR 60 ...

Six months have already passed since the end of Sep 2018, quite a lot in terms of GitHub implemented code changes; it does appear as though major "legacy" browsers breakage occurred during the last month or so... :angry: Firefox versions < 52.0 don't function correctly at GitHub despite a SSUAO to FxESR60, because they can't handle served JS code; as for Chromium based browsers, I don't use them much, but here are my observations:

1. Google Chrome 49.0.2623.112 and 50.0.2661.102 (last working in Vista) could be made GitHub compatible via the User-Agent Switcher for Chrome extension and a SSUAO for GitHub as Opera/Vivaldi/Fx60; now, this no longer works (you don't get the yellow header about an unsupported browser version, but major parts in the webpage just don't work!)

2. Opera 36.0.2130.80 and 37.0.2178.54 (last working in Vista) would support GitHub natively, but they no longer do (even when spoofed to later Chrome/Opera/Firefox versions...).

3. Yandex Browser 17.4.1.1026 (Chromium 57 based) and 17.6.0.1633 (Chromium 58 based - last working in Vista) would support GitHub natively; currently they don't out-of-the-box, but you can resume GitHub functionality if you install aforementioned extension (User-Agent Switcher for Chrome) and add a permanent spoof (i.e. SSUAO) "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Firefox/60.0" for domain "github.com"

7 hours ago, Alex654 said:

What are the new features that are not supported

Currently in NM27 (as well as the other "legacy" browsers where GitHub is broken):

NMU6Du1.jpg

Selecting a different branch via the dedicated button/wizard is broken; clicking the ellipsis in the commit title to expand it is broken; clicking the dedicated button to copy commit hash broken; various other more complex functions are broken, too (editing a previous issue/comment, "preview" tab in posts, etc.) :realmad:

7 hours ago, Alex654 said:

and why GitHub had to deploy them, don't you know?

Not the right person to ask that ;)

7 hours ago, Alex654 said:

as for the extensions, I already have tried one, the result is described above - it failed to deal with the CSP directive.

UXP browsers don't require an extension to make SSUAO work; this is a supported and native platform feature; as for FirefoxESR 52.9.x (where the feature is extant but dormant), I had toyed with the following extensions in the past;

HeaderEditor 4.0.7 (WE)
Custom User Agent 0.1.7 (WE)
Custom User Agent 0.1.5 (jetpack/legacy)
HTTP Header Mangler 1.1.3 (WE)
HTTP Header Mangler 1.1.2 (jetpack/legacy)
UAControl 0.1.3 + User-Agent JS Fixer 1.3 (both legacy)

that all allow for URL/domain specific UA spoofing and, AFAICT, all performed the task brilliantly; lately, I have opted to ditch the UA modifying extensions and go for the "native" fix (by the insertion of the two .js files into InstalDir, see here).

I don't use GitHub myself for code authoring/manipulation, but for every other feature I use it for, I encounter no issue when using latest New Moon 28[5.0.a1]/Serpent 52.9.0 with a SSUAO/FirefoxESR 52.9.x with a SSUAO; granted I, too, get a CSP error in WebConsole:

xm8E2qR.jpg

but whatever it may actually signify, my GitHub usability seems unaffected... ;)  @Alex654, you seem very well versed when it comes to Javascript language, perhaps you should explain in more detail where exactly GitHub fails for you; other coders here could offer substantial assistance (other than me saying GitHub just works in NM28 :lol:) ...

Best regards

Edited by VistaLover

Share this post


Link to post
Share on other sites
5 hours ago, Alex654 said:

What are the new features that are not supported and why GitHub had to deploy them, don't you know?

The "new feature" is that it won't work unless you're using (or can fool GitHub into thinking you're using) the latest "greatest" browser to access their site. That may not seem like much of a "feature" to you or me, but it's definitely a "feature" to GitHub's owner, Micro$oft: it sells Windows updates since those browsers won't run on Vista or earlier Windows versions.

I'd guess that GitHub sends every browser (except a few specific ones) JavaScript based on the ECMAScript 2018 standard, which won't work on anything but the newest browsers. Luckily, if you pretend to be 60.x, that's one of the few browsers that will get "legacy" JS based on ECMAScript 2017 :rolleyes: which NM 27 still can't completely handle ...

6 hours ago, VistaLover said:

What is indeed ominous is the fact FirefoxESR 60 is currently at version 60.6.1; when it reaches v60.8.x in 3-4 months, it'll be EoS and thus become unsupported by GitHub; then their ESR support will swift to v67; it is questionable whether the code they'll be serving to that would still be backwards compatible (via a SSUAO hack) with ESR52/UXP; I trust the Moonchild Productions devs would do their best to restore GitHub support in their UXP platform...

I've been wondering about that myself. I would assume MCP will try either to backport the necessary JS enhancements or to update the JS engine themselves, but one wonders how practical that will be - and there's some chance they'll have to throw in the towel on UXP, and PM 29 will be Quantum-based....

  • Like 2

Share this post


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

In the case of Serpent 52.9.0, I find a simpler SSUAO also works:


general.useragent.override.github.com;Mozilla/5.0 (Windows NT 6.1; rv:52.0) Goanna/4.1 Basilisk/52.0

 

I think that's actually the default (well, except for the Win 7 part) if you don't turn on FF compatibility; if you do turn on FF compatibility, you get a "mixed" user agent string by default that includes both Firefox and Palemoon/Basilisk. (By default the FF part of the string claims 60.9, at least with Basilisk/Serpent.)

I don't trust that default, though; I use a "pure" Win 7, FF 60.9 user agent string as my default. That does cause a few problems with other sites, such as Instagram; most of those sites then get SSUAOs to Win 7, FF 52.9.

Share this post


Link to post
Share on other sites
Posted (edited)

An excellent post by Matt Tobin over on the PM forum :

 

Quote

I should address the whole reforking bit and sum it up quickly.

When we created Tycho (Pale Moon 27) from a hybrid of our own independent development being ported to a platform base of ESR38 plus the Pale Moon 24-26 application code completely bypassing and removing the "native" Firefox application code that came with the esr38 tree we expected that would be the last time we would do such a thing. We had a good foundation and retained 1:0.975 of Pale Moon as an application.

The reason we expected Tycho to be the last time was because by the next ESR Mozilla had planned to destroy enough of its self that the foundational technologies such as xul, xbl, xpcom, etc would be a shadow of their former selves if not changed to a degree that was simply unuseable to anyone outside of MozCo or simply gone.

Obviously, this wasn't the case when we or they thought it would be. ESR45 was largely okay but it wasn't enough to justify a jump in our eyes since so much more development on Tycho had happened since. Especially in the media subsystem. Why throw that away?

Well Mozilla has been known to take forever to do things and rabid release never changed that just increased the pace of immature code changed being shipped out to end users. Surely, the next ESR would be too damaged to use right? So Tycho continued.

Enter ESR52, well more destruction happened and more co-op of fundamental technologies happened but also some good css and js support of a significant nature was present. Still we didn't want to throw Tycho away so we continued on back porting and continuing forward with our own independent development.

Then Firefox Quantum happened along with the end to mozilla-style extensions (xul/toolkit/overlay, bootstrap, jetpack). Well now we have reached an issue.. Mozilla has finally begun the final destruction of their technology. All of it was fair game. On one hand we were glad they were finally doing it without any pretense anymore but on the other hand we were saddened by the tragic destruction without even the thinest of hopes left that they may change course and avert it.

Moonchild being Moonchild decided that the Quantum and general extension refugees deserved a browser that unlike Pale Moon would stay much closer to what they had then and there. An Australis Firefox drop in replacement. Many of this second major wave of Mozilla refugees were less likely to fit into the Pale Moon box and just wanted then current day Firefox. Of course, he would scrape off the surface garbage like pocket and other Mozilla Service tie-ins. This became Basilisk.

With Basilisk came a platform, of course. We knew we couldn't maintain two platform codebases in the long term so the Moebius project started with the intent to port Pale Moon to it as well just like we did with Tycho. However, in the meantime Basilisk and the moebius platform needed to reach a polish level beyond Mozilla before that could happen.

Moonchild proceeded from a code standpoint of gecko/53 as a base backporting from 54 and 55 heavily. This is why Basilisk carried a Mozilla version number of 55 during that time. After some months Basilisk was released but development continued.

With the dawn of 2018 came my resurgance in participation in the Pale Moon project. Besides, it was I who conducted the primary vNext research that lead to inital porting up the line that helped make Tycho possible.

Well it was time to pull the same trick twice but there was a problem.. Unknowingly Mozilla has landed a refactoring storm of changes directly after 52 that largely made the platform difficult to unuseable to anything but Firefox (there were workarounds for SeaMonkey and Thunderbird in dev but not been fully worked out yet).

This was game ending for Pale Moon that would either spell delays and potental busting of Pale Moon on some fundamental levels or just take too damned long to reverse in the platform. We were stuck.

Then I checked ESR52 and it was suitable so I drafted the Take 2 plan for the Unified XUL Platform. ESR52 based UXP had several pros and cons. The cons are obvious, lose all the work we did with Basilisk and Moebius as well as more backporting work. The pros however are abundent. If we ARE to use the platform AS a platform we should use the most historically complete version of it that also matches current day platform code of other projects that will reach deadends at Mozilla. Also, Pale Moon will work with standard porting stratagy developed during vNext no problem.

Take 2 was agreed on and that is where we are today with Pale Moon, Basilisk, and the other allied and non-aligned UXP based projects.

Make no mistake this is it. There can never be another vNext type of forking situation. There isn't enough of the Mozilla technology left in the now fully firefox codebase. It isn't even a platform codebase for many apllications anymore. Not even Firefox first. Just.. Firefox.

If you want more express detail then ask but this hasn't been as short as I would have expected but I don't think it could have been told with any fewer words than it was.

 

https://forum.palemoon.org/viewtopic.php?f=4&t=21772

Edited by dencorso
Quotation Tags... do they ring any bells?
  • Like 1

Share this post


Link to post
Share on other sites

The nice thing about open-source software is that nothing ever goes away completely. Moebius may have been a dead end for PaleMoon but it's still a useful and (with TenFourFox's and @roytam1's help) secure browser. In some ways it's the most advanced browser available for Windows XP and Vista.

I use Serpent/UXP vs. Serpent/Moebius because it has better compatibility with FF 52 ESR, and it benefits from MCP's current development efforts, but I understand why some folks choose Moebius (especially since MCP's understanding of "development" occasionally means removing useful browser functionality).

Share this post


Link to post
Share on other sites
20 hours ago, roytam1 said:

if there is a need of this, I can restore it by reverting them.

 If I am to respond to this query myself, I was indeed aware of the "Container Tabs" (aka Contextual Identity) browser feature being present in FxESR 52 (and thus inherited as dormant code inside the UXP platform) from my Firefox Nightly tester era; it was first offered as an experiment during the 50.0a1 dev cycle (June 2016) and was still present at the start (Nov 2016) of the 53.0a1 dev cycle when, alas, I was violently kicked out, as my OS became unsupported... :realmad:

 I read that further down its development the feature was offered through the, now defunct, Test Pilot project, morphing finally into a standalone WebExtension addon (Firefox Multi-Account Containers - v4.0.2 the last compatible with FxESR 52).

 FxESR 52 shipped with the feature pref'd off by default; the hidden pref "privacy.userContext.ui.enabled", when toggled, exposes a GUI setting at the bottom of "about:preferences#privacy" tab, where the feature can be more easily enabled/disabled (toggling in effect hidden preference "privacy.userContext.enabled").

 While that feature does hold promise, it actually never caught up with me, i.e. I rarely used it in Firefox; so at present I'd say I'm indifferent to its presence inside Serpent 52.9.0; in the few instances where I need an isolated (contained) tab, I make use of the Private Tab extension (as stated already) ...

 But my personal opinion shouldn't carry any weight in the decision-making wrt this feature inside Serpent; at least two other MSFN members+Serpent users expressed a wish it stays in, so I think the focus should shift to how many actually used it up until recently and have a concrete desire to continue using the feature in future Serpent builds :P ; I'm OK either way it goes!

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...