Jump to content

My Browser Builds (Part 1)


Recommended Posts

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
Link to comment
Share on other sites


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
Link to comment
Share on other sites

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
Link to comment
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.

Link to comment
Share on other sites

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
Link to comment
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....

Link to comment
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.

Link to comment
Share on other sites

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?
Link to comment
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).

Link to comment
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!

Link to comment
Share on other sites

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

Alex 654 said:


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.


If all else fails or is forbidden on certain domains, spoofing useragents in Firefox52 is still easy without any extension:
general.useragent.override = Mozilla....

Raw basic method. That UA-string simply gets sent to all domains, not just single ones.
Works since ancient times and in FF52 too without any additional initialization, unlike site-overrides.
The only catch is that all those header addons must be disabled to avoid hijacking. As usual, after addon install changes it often helps to delete their startupCache folder in the profile.

(Being stuck on a much older browser myself, struggling with broken websites all the time, it's often even necessary to kill the stylesheets after loading. For example here too, to get the Edit link ;-) Also a very powerful method to get some hidden or broken stuff partly accessible again) Edited by siria
Link to comment
Share on other sites

Quote

Don't it always seem to go; you don't know what you've got 'til it's gone....

I'm still trying out containers. I've found it useful for logging into both my and my wife's bank account at once, without having to go to about:profiles, set up a second profile, install all my add-ons and custom prefs, etc. And the color-coding helps me keep track of which tab is for which person.

That's about it so far, but remember - I only learned of it because MCP stripped it out and drew out the one person on this thread who uses it!

I'd encourage others who find the containers concept intriguing to download the 3/23 version of NM or Serpent, toggle on the prefs, and give them a try. To be fair, perhaps you should also try the 3/30 version and see if you notice better performance opening tabs, etc. with the feature removed.

The feature could use improvement. I'd like to see a way to associate a bookmark with a container, so you just click, say, the Amazon bookmark, and Amazon opens up in a new "shopping" container tab. That would save key/mouse strokes vs. opening the container first, then opening the bookmark.

Perhaps MultiFox will mature someday, and the built-in support for containers can then be removed.

BTW, I also installed the private tabs extension. A private tab is sort of a "throwaway" container tab: open one and you have a new container; close it and the container is gone for good, including any cookies or unexpected NSFW content (although I'd probably flush my cache anyhow just to be sure). Excellent option for the first visit to a site you aren't sure you can trust.

Opera 12 had private tabs and I've missed the feature in Firefox and Serpent. The latter have private windows but those aren't as convenient.

Link to comment
Share on other sites

23 hours ago, roytam1 said:

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

Wish they would stop arbitrarily removing useful features but if you can restore this one without a lot of extra work that would be great. If not there's always 52 or 60esr but for me it's mainly the convenience of having it in the browser you're using most of the time.

Link to comment
Share on other sites

10 hours ago, DanR20 said:

there's always 52 or 60esr

FF 60 ESR actually isn't bad - I have a copy on my Win 7 PC - but

  1. It doesn't run on XP/Vista and cannot be made to do so
  2. It doesn't support NPAPI plug-ins, nor does it offer a substitute like PPAPI; say goodbye to Java, Silverlight, etc.
  3. It doesn't support any pre-WE add-ons
  4. Last (and TBH, least) it sports a new UI, which wouldn't be bad if it didn't look so much like Win 10 :puke:

Basically, it's a brand-new browser that happens to be somewhat compatible with your old FF profiles. About the only thing it has in common with FF 52 ESR is the name (and a few WE add-ons).

Link to comment
Share on other sites

On 4/2/2019 at 8:21 PM, VistaLover said:

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

According to the wiki, the add-on provides some improvements over the support built into FF 52 and Serpent. Unfortunately, I just tested version 4.0.2 of Multi-Account Containers, and my experience matched @DanR20's:

On 4/1/2019 at 11:57 AM, DanR20 said:

I tried installing the Multi-Account Containers addon but all it gives me is a thin line down below the toolbar button and nothing else.

So it looks like 4.0.2 installs but doesn't run correctly, whether or not the built-in support is present. Same result in Serpent and FF 52.9.1.

I'll try some older versions and report back. Edit: I tried several versions all the way back to 2.3.0. They all do the same thing as 4.0.2.

Edit 2: v4.0.2 of the add-on works in Serpent/Moebius! In fact versions up through 4.1.0 are compatible with Moebius.

BTW, the add-on does make containers quite a bit easier to use. To open a new container tab, you don't have to go to the File menu; when clicking the "new tab" (+) button just hold the mouse button down for a second or two, and the "new container tab" menu will appear. Also you can right-click on a Web page and click "Firefox Multi-Account Containers / Always Open in This Container" to "pin" the current site to the current container. Then, any time you click a bookmark or link for that site, you get asked whether to open the link in the current container or in the "pinned" container for that Web site.

Edit 3: You can enable the new container menu from the new tab (+) button without the add-on, so it can be used in Serpent/UXP. Just create a new integer pref named privacy.userContext.longPressBehavior and set it to 2. Other add-ons that change the behavior of the new tab button may keep this from working, though :(

Edited by Mathwiz
Link to comment
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...