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)
16 hours ago, VistaLover said:

only difference to mine is I pinged IP 104.27.137.100 (from Greece), while he pinged the alternate IP 104.27.136.100 (from Italy)

Well, any difference needs to be tested. Like you I get 104.27.137.100. So, I used my hosts file to force my browser to access 104.27.136.100 instead when I enter o.rths.cf in the address bar. Perhaps the .136. one was down?

But both IP addresses work, so both server IPs are on-line. The issue is neither with the DNS, nor the server; it must be with CloudFlare's routing.

So I say again:

On 7/28/2019 at 11:12 AM, Mathwiz said:

Probably need to contact CloudFlare. Sounds like their network is fouled up somewhere between Rome Europe (including Rome, and at least for the next few months, London; let's not get hung up on the difference between the PC's local CloudFlare node and the smart phone's, OK?) and wherever o.rths.cf is. (Wikipedia says .cf is the Central African Republic, but the CAR is probably just letting CloudFlare use their TLD for a fee.) 

In the meantime I'm afraid @Sampei.Nihira will just have to use the Web proxy he found.

Edited by Mathwiz

Share this post


Link to post
Share on other sites

Posted (edited)
On 7/20/2019 at 6:59 AM, sparty411 said:

Is BOC (BNAV) a replacement for New Moon?

One aspect of BNAV (BOC) Browser is that the DEFAULT THEME does NOT have it where the ACTIVE Browser TAB is (differently) more brightly colored than the other TABS. I addressed that issue here at this URL below:
https://msfn.org/board/topic/177125-my-build-of-new-moon-temp-name-aka-pale-moon-fork-targetting-xp/page/146/?tab=comments#comment-1164249

My view (as 'Mathwiz' said), it is a matter of preference between NM28 vs BNAV (BOC) Browsers. I have both of these Browsers installed here. And I have better luck with SP55 Browser than SP52 Browser. No substitute for 'hands on' testing?  :)

My above URL here gives reference for modifying SeaMonkey LANGUAGE PACKS to work
with BNAV (BOC) Browser. RT did explain how to do it.

Edited by TechnoRelic

Share this post


Link to post
Share on other sites
Posted (edited)

@roytam1

Using latest Serpent52 win32 build, I loaded

https://www.bbc.co.uk/taster/pilots/casualty-ae-audio/try

but the embedded web player fails to load:

FuvJlg1.jpg

For debugging purposes, I disabled uBlock0; no other content/script blocker used.

OTOH, latest 360ExtremeExplorer (11.0.2140.0) has no issues loading it (and playing back the clip):

pztfc7g.jpg

The issue I experienced might well be Javascript and/or CSS related; the workaround I found is right-click the empty web player and select "This Frame => Show Only This Frame" :

wRSlJk1.jpg

Any suggested fix would be welcome :) ; ultimately, if it is reproducible in official Serpent 52.9.2019.06.08, it should be submitted to the official forums; mind you, it is only available for a month or so... :(

Edited by VistaLover

Share this post


Link to post
Share on other sites
Posted (edited)

I managed to break FF52-based Basilisk(instacrash on startup), so I moved session to the less updated FF55-based branch where I was able to start and undo settings.
Here, they just seem to reduce performance(at least in Discord).

I was unable to view webgl on some site, in FF52 Basilisk, so I decided to toy around with about:config settings, then restarted browser. Crash.
One of these(or a combo thereof), broke the browser:
- layers.acceleration.force-enabled: true
- layers.prefer-opengl: true
- webgl.force-enabled: true

My config is:
- gpu: nVIDIA Quadro 600, driver version 368.81
- os: Win XP SP3 x86 with "SP4" updates

Edited by 404notfound

Share this post


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

I was unable to view webgl on some site, in FF52 Basilisk, so I decided to toy around with about:config settings, then restarted browser. Crash.
One of these(or a combo thereof), broke the browser:
- layers.acceleration.force-enabled: true
- layers.prefer-opengl: true
- webgl.force-enabled: true

My config is:
- gpu: nVIDIA Quadro 600, driver version 368.81
- os: Win XP SP3 x86 with "SP4" updates

It was likely the highlighted one. I have XP x64 install with same NVIDIA driver version, though a different GPU (GeForce GTX 750 Ti) and this one just makes the browser crash in xul.dll.

Also, just having hardware acceleration enabled in Preferences makes the experience beyond awful. Moving the browser to the secondary screen just makes the whole browser stutter; videos stutter, animations stutter, heck, even mouse cursor gets laggy. Same issue with Firefox 52. And to top it off, having browser opened for longer time and invoking other applications utilizing hardware acceleration quickly makes the browser memory usage increase rapidly, then it crashes in d3d9.dll. When whatever causes rapid memory usage occurs, the state becomes corrupted to the point that if I manage to restore its window, the entire window client area is already messed up (just blackness).

Having hardware acceleration disabled has some weird effect on font rendering in certain cases, so far, I only noticed it on YouTube's player.

Anyway, @404notfound, the pref you're probably looking for is webgl.disable-angle.

Share this post


Link to post
Share on other sites

PM28, WinXP

My CPU had been racing on several web pages.  I tried several things, which eventually led me to rebuild my browser from scratch.  In doing so, I wished to run two instances of the browser, and used the command switches -profile <path> --no-remote.

To my surprise, my CPU issues went away, I guess because of the use of --no-remote.

Share this post


Link to post
Share on other sites

Ublock seems to fail spontaneously and stop filtering altogether with FF 55-based Basilisk, needing reinstall of the XPI for it to work again.
I am using the uBlock0.firefox-legacy.xpi I found on Roytam's server.

ublock_fail.png

Share this post


Link to post
Share on other sites
27 minutes ago, 404notfound said:

Ublock seems to fail spontaneously and stop filtering altogether with FF 55-based Basilisk

because ub0 tries to use more "modern" WE APIs that SP55 doesn't afford in later builds(IIRC ~1.18+).

Share this post


Link to post
Share on other sites
Posted (edited)

@404notfound Everything is working as expected here:

7mFVYGC.jpg

uBlock0-legacy v1.16.4.11 installed from GitHub: 

https://github.com/gorhill/uBlock/releases/tag/firefox-legacy-1.16.4.11

But the main thing to consider is that Serpent 55.0.0 on the Moebius platform can still connect to AMO (addons.mozilla.org) to check for extension updates, where St55 poses itself as Firefox 55.0; in reality, St55 has been forked from Firefox 53.0a1 and its WebExtension support is even inferior to stock Fx 53.0 (!). 

By default, St55 will update the legacy v1.16.4.11 of uB0 to v1.17.4 of the WE type, which, unfortunately, depends on WE APIs not (enabled/)found in Moebius (as pointed out by @roytam1), hence the issue you report...

The way to workaround this has been posted many a times in this thread, by several members, including both me and @Mathwiz : install (from GitHub) the companion extension called uBlockOrigin Updater:

https://github.com/JustOff/ublock0-updater/releases

IzVeqRa.jpg

Its action is two-fold:

1. Thwart Serpent 55 from making uB0 (extension) update calls to AMO (so it won't peak the incompatible WE version)

2. Keep an eye on uB0's GitHub repository for the appearance of an updated "legacy" version and either auto-install it or notify/prompt the user to install manually (according to user preferences).

Hope it's all clear now :P

 

Edited by VistaLover

Share this post


Link to post
Share on other sites

Without uBlock Origin Updater, Serpent 55 (Moebius) will self-update to 1.18.4 (or possibly later); Serpent 52 (and FF 52.9) will self-update to 1.17.4*.

Surprisingly, the new versions mostly work with Serpent (& FF), but there are a few features that don't, presumably due to WE APIs missing in versions before FF 55. For example, in the Dashboard / Settings / Privacy, the "Prevent WebRTC from leaking local IP addresses" setting is greyed out.

So I stick with the so-called legacy version (1.16.4.11), use uBlock Origin Updater to keep me there, and am able to check that privacy setting.

 

*Digression: it is possible to run uBO 1.18.4 with Serpent 52/FF 52.9, but several hoops must be jumped through (more on FF than Serpent), and since 1.16.4.11 works better anyhow, I don't feel it's worth the effort.

Share this post


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

Without uBlock Origin Updater, Serpent 55 (Moebius) will self-update to 1.18.4 (or possibly later);

Not according to tests I conducted prior to my reply above...

Steps to reproduce:

1. Start with a new pristine Serpent 55 profile, using latest binary package offered by Roy:

basilisk55-win32-git-20190622-c2dfff698-xpmod.7z

2. Manually install

https://github.com/gorhill/uBlock/releases/download/firefox-legacy-1.16.4.11/uBlock0.firefox-legacy.xpi

k3aiB1q.jpg

3. Switch to Addons Manager (about:addons) tab, select the entry for uB0 1.6.4.11 and manually check ONCE for updates (right-click => Find updates); it will get updated first to 1.17.4 (WE):

ph9p0Nd.jpg

4. On the uB0 1.17.4 AOM entry now, just check again manually for an update; this time you won't be offered an additional update to a higher version; these have been my findings under Vista SP2 x86, where St55's default UA is

Mozilla/5.0 (Windows NT 6.0; rv:55.0) Gecko/20100101 Goanna/4.0 Firefox/55.0 Basilisk/20190622

NCUic5N.jpg

5. If I let Serpent 55.0.0 (new clean profile with only uB0, v1.6.4.11 manually installed and afterwards manually updated to v1.17.4) stay open but idle for a duration of, say, 15min, by coming back at it I find it has auto-updated to latest (AMO) v1.21.2:

hNLz8q1.jpg

NB that 1.21.2 is totally broken on Moebius under that test profile,, without even a glimpse of a toolbar button (not even in "Customize" mode); the dashboard, accessible via about:addons => uB0 => Options, is totally empty, too...

So, one's tests with uB0 WE on Moebius is probably a case of YMMV :angry:

Share this post


Link to post
Share on other sites
23 hours ago, mraeryceos said:

PM28, WinXP

My CPU had been racing on several web pages.  I tried several things, which eventually led me to rebuild my browser from scratch.  In doing so, I wished to run two instances of the browser, and used the command switches -profile <path> --no-remote.

To my surprise, my CPU issues went away, I guess because of the use of --no-remote.

Any side effects?

Share this post


Link to post
Share on other sites
23 hours ago, mraeryceos said:

I guess because of the use of --no-remote.

Highly unlikely :P ; you rebuilding your browser profile from scratch was what probably fixed your CPU issues (possibly some conflicting extensions/preferences/about:config settings were the cause of elevated CPU cycles in your original profile...).

FWIW, --no-remote is just a cmd line switch that means "don't talk to an existing Firefox, start a new instance"; together with the -p switch, one is able to launch a new Firefox (or fork) instance loading the specified profile, so that the two Firefox instances one ends up with are completely separated!

For anyone that cares, there exists an excellent article dedicated to the switch in question, found here :)

  • Like 1

Share this post


Link to post
Share on other sites

Ah whoops!

So the problems I was having with ublock0 were because of automatic updates.

  • Upvote 1

Share this post


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

Highly unlikely :P ; you rebuilding your browser profile from scratch was what probably fixed your CPU issues (possibly some conflicting extensions/preferences/about:config settings were the cause of elevated CPU cycles in your original profile...).

FWIW, --no-remote is just a cmd line switch that means "don't talk to an existing Firefox, start a new instance"; together with the -p switch, one is able to launch a new Firefox (or fork) instance loading the specified profile, so that the two Firefox instances one ends up with are completely separated!

For anyone that cares, there exists an excellent article dedicated to the switch in question, found here :)

No.  Because I ended up continuing to use the browser profile without rebuilding it from scratch :-)  So as far as I can tell, given I made no other changes, it is the only reason.

The only side effect to using the switch, is that I can't launch a link in my browser from another application.  I will eventually remove the switch to see if it is reproducible, but right now, I'm too much enjoying my browser running so smoothly.

Edited by mraeryceos

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