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

Games swf problems:

4cbc546888bfc949gen.png

Share this post


Link to post
Share on other sites

59 minutes ago, kitaro1 said:

Games swf problems:

4cbc546888bfc949gen.png

this looks familiar, seems to be some old flash bugs

Share this post


Link to post
Share on other sites
Posted (edited)
On 5/18/2019 at 7:06 PM, looking4awayout said:

EDIT 2: I just stumbled upon another bug. When I open the "Find in This Page" feature, the browser crashes giving me a System Exception error. If necessary, I can post a screenshot.

reproducible here, will try to fix it later.

EDIT: OK, please redownload firefox-45.9.15-20190511-bdebcdb5e-win32-sse.7z

Edited by roytam1
  • Like 1

Share this post


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

reproducible here, will try to fix it later.

EDIT: OK, please redownload firefox-45.9.15-20190511-bdebcdb5e-win32-sse.7z

Great! Thanks!

Share this post


Link to post
Share on other sites

In mypal28.5.0 there is no problem with swf, but has a problem with the polish language pack.
Such is the fate of an old man.

Share this post


Link to post
Share on other sites
Posted (edited)
On 5/20/2019 at 9:36 AM, kitaro1 said:

In mypal28.5.0 there is no problem with swf, but has a problem with the polish language pack.

https://o.rths.cf/boc-uxp/
BNAV Browser (RT)

https://msfn.org/board/topic/177125-my-build-of-new-moon-temp-name-aka-pale-moon-fork-targetting-xp/page/101/?tab=comments#comment-1158936
BNAV Browser (RT) -- Supports LANGUAGE PACKS via modification of XPI file at URL above.

https://www.seamonkey-project.org/releases/#langpacks
There is a POLISH Language Pack available.
https://archive.mozilla.org/pub/seamonkey/releases/2.49.4/langpack/seamonkey-2.49.4.pl.langpack.xpi

http://gameswf1.weebly.com/uploads/2/0/0/6/20065369/____pacman-flash.swf
PACMAN Game (URL above) worked well for me.

I have NO IDEA if that the 'BNAV Browser (RT)' supports ALL that you need it.
LEGACY Extensions supported: uBLOCK Origin -- User Agent Switcher -- (And More LEGACY SM Extensions)

Edited by TechnoRelic

Share this post


Link to post
Share on other sites
On 5/20/2019 at 3:27 PM, looking4awayout said:

Great! Thanks!

i wonder how you could make SSD-drive working on your P3! cannot install on GA-7N400Pro2 and on Asrock Alive-Dual eSata2 had to attach on second channel using a different chipset.

Share this post


Link to post
Share on other sites
On 5/16/2019 at 5:42 PM, looking4awayout said:

I have just tried the newest version of Firefox 45 ESR SSE (45.9.15) on my Pentium III RDD, and compared to the older versions, I noticed that scrolling in webpages appears to be choppier, less smooth than it is for example on New Moon 27 and the older versions of FF45 ESR SSE. To make sure it wasn't an impression of mine, I rolled back to 45.9.14 and the latest stable version, 45.9.11, and I've indeed noticed that the older versions are way smoother when scrolling websites, even with pictures (especially after applying the UOC Patch). I noticed that in 45.9.15, when I scroll a website with pictures that are loading, the scrolling noticeably lags, while in the older versions it scrolls almost seamlessly when pictures are loading, at least with the UOC Patch enabled. I hope this choppy scrolling issue can be addressed and eventually fixed, as I've currently rolled back to 45.9.11, which behaves as fine as 45.9.14 on my machine. A big thumbs up to @roytam1 for his great work, and I hope my report can be useful. :)

Pls lead me to the UOC Patch

  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)
6 minutes ago, 3dreal said:

Pls lead me to the UOC Patch

A simple forum search could have easily taken you there :P:

 

Edited by VistaLover

Share this post


Link to post
Share on other sites
On 5/8/2019 at 4:01 AM, Mathwiz said:

Whether or not Tab Tally works as the developer intended, it works the same way in Serpent and Firefox. In fact, in my experience, compatibility between FF 52 and Serpent 52 is excellent. If an add-on works in Firefox, it's all but certain to work in Serpent too.

... Let us just revisit Tab Tally, shall we?

https://addons.mozilla.org/en-US/firefox/addon/tab-tally/versions/

All versions currently listed on AMO are, of course, of the WE format; version 1.0.0 is advertised as being compatible with Firefox 49.0+, versions 1.1.0 through to 1.3.0 advertised as being compatible with Firefox 48.0+; I was particularly interested in one of those older WE versions, because they duplicate the functionality of the XUL ("legacy") version 0.1.1, now removed from AMO (but is recoverable via the CAA extension).

All (WE) Tab Tally versions 1.0.0 to 1.3.0 install and function properly in Firefox ESR 52.9.0[1] ; "properly" is actually the "desired-by-me" way (constant visual display of the number of tabs, updated in real time when that changes...); of course, the latest version 1.4.0 also installs there, but with a slightly degraded (IMHO) functionality...

But trying to install any one of Tab Tally versions 1.0.0 to 1.3.0 in Serpent 52.9.0, you'll be met by a failure to install in the form of message:

wXXxdqE.jpg

That's because v1.0.0 to 1.3.0 are id-less WEs (one only has to inspect their manifest.json files) and Serpent 52 lacks the API to allow installation of id-less WEs (but FxESR 52 does support that API).

In version 1.4.0 of Tab Tally, the author re-introduced the "WE-id" feature inside the manifest.json file:

  "applications": {
    "gecko": {
      "id": "@tab-tally"
    }
  }

and made it compatible with even older Firefox versions (min version lowered from 48.0 to 42.0) and, probably unbeknownst to him, also restored St52 compatibility; 1.4.0, as discussed previously in this thread, would install fine in St52 (but not v1.0.0-1.3.0, which do install and work fine under Firefox ESR 52.9.0... ) ;)

 

  • Like 1

Share this post


Link to post
Share on other sites

Is it a bug or not? Try to speed up or slow down some Youtube video (w/o hardware acceleration). When I do this my CPU is running at about 80%. Mypal (Feodor2's) mod v28.4.1 works fine, at almost the same CPU usage. Tested with roytam1's mod v28.5.0a1 and some old builds. Windows XP x86.

Share this post


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

Tab Tally versions 1.0.0 to 1.3.0 install and function properly in Firefox ESR 52.9.0[1] ; "properly" is actually the "desired-by-me" way (constant visual display of the number of tabs, updated in real time when that changes...)

Excellent detective work:

17 hours ago, VistaLover said:

In version 1.4.0 of Tab Tally, the author re-introduced the "WE-id" feature inside the manifest.json file:


  "applications": {
    "gecko": {
      "id": "@tab-tally"
    }
  }

and made it compatible with even older Firefox versions (min version lowered from 48.0 to 42.0)

So, I had to know: since versions prior to 1.4.0 work in FF 52, could, say, 1.3.0 (which I agree has superior functionality) be "fixed" to run in Serpent, simply by adding the above block to its manifest.json file?

Yes! I just tried it; of course changing manifest.json invalidates the sig, but unlike FF, Serpent doesn't care about that (actually my copy of FF has been set not to care about it either, but you don't need to "fix" Tab Tally for FF anyhow); and with that change, Tab Tally 1.3.0 installs and runs in Serpent fine! :D

17 hours ago, VistaLover said:

v1.0.0 to 1.3.0 are id-less WEs (one only has to inspect their manifest.json files) and Serpent 52 lacks the API to allow installation of id-less WEs (but FxESR 52 does support that API).

Not a huge deal, but I wonder why the heck that function was removed? Was this just another case of MCP getting rid of code they didn't think the browser needed, as they did with all WE add-ons later?

  • Like 1

Share this post


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

I wonder why the heck that function was removed? Was this just another case of MCP getting rid of code they didn't think the browser needed, as they did with all WE add-ons later?

... I spent the better part of last hour researching and reading on this ;) ; the ability to install id-less extensions from AMO into Basilisk was lost (what is called a regression) when the MCP devs decided to remove the internal platform mechanism that effectuated extension signature verification; this happened early on during Basilisk's development, when the (experimental at the time) application was "baking" on top of the (now deprecated) Moebius platform... 

Put very simply, id-less extensions acquire first a temporary (internal) id and then a permanent one, whose strings are derived from their verified signature hash; you need to have a working internal mechanism to process the add-on's signature and then generate valid id strings for the installation to succeed; but the devs in Moebius wanted to remove that mechanism altogether and not just allow the installation of unsigned extensions, because then unsigned installed extensions would produce warnings inside about:addons (Add-ons Manager, AOM); this is indeed what happens when you install unsigned extensions in FxESR 52 with the pref xpinstall.signatures.required set to false (NB that, as I have posted in another thread, extension signature verification - in FxESR 52 - is still performed in the background for already installed signed extensions and will also be triggered when a new signed extension is about to be installed!). 

There wasn't uniform agreement between the dev team which features inherited from Mozilla should be kept and what regressed functionality should be restored; Moonchild himself wanted to cut-off reliance on Mozilla-issued certificates (in hindsight, he was probably right, given the recent - May 3rd - armagaddon-2.0 Mozilla debacle), that meant removing the signature verification code; an "incomplete" workaround was implemented in PR #279 (see below); in any case, the focus of the team was always on Pale Moon (which, by design and choice, doesn't support WEs at all), as for Basilisk's inherited WE support, it wasn't very high on their agenda at the time (and we all know how that ended! :P).

If you've got spare time to spend, some Moebius era GitHub issues and pull requests are linked below: 

Addons - Can't install some addons: https://github.com/MoonchildProductions/moebius/issues/238

Add ID from a signature if it isn't included in manifest.json: https://github.com/MoonchildProductions/moebius/pull/251

Fix signed extension checks: https://github.com/MoonchildProductions/moebius/issues/277

(emphasis should be put on Moonchild's comment below:

https://github.com/MoonchildProductions/moebius/issues/277#issuecomment-356231470 )

Get IDs for ID-less WebExtensions without breaking normal libJAR signature checking: https://github.com/MoonchildProductions/moebius/pull/279

Then the Moebius platform was left to rot... When Basilisk was later ported to UXP Take 2 (now just UXP), the issue of id-less WEs resurfaced: 

https://github.com/MoonchildProductions/UXP/issues/373

but Moonchild decreed:

Quote

ID-less web extensions are a no.

and he "WON'TFIX"-ed that issue... :angry:; moot point now in the case of official Basilisk, still an issue with the Serpent 52 fork... :(

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

Disclaimer: Had a rough day today :}, so I might have not grasped 100% correctly what was contained inside the devs' exchanges in the linked issues/PRs; I have the sense the "general idea" is there, but anyone is free to correct any misunderstandings on my part... ;):)

Edited by VistaLover

Share this post


Link to post
Share on other sites
21 minutes ago, VistaLover said:

Moonchild himself wanted to cut-off reliance on Mozilla-issued certificates (in hindsight, he was probably right, given the recent - May 3rd - armagaddon-2.0 Mozilla debacle), that meant removing the signature verification code; an "incomplete" workaround was implemented in PR #279 (see below); in any case, the focus of the team was always on Pale Moon (which, by design and choice, doesn't support WEs at all), as for Basilisk's inherited WE support, it wasn't very high on their agenda at the time (and we all know how that ended! :P).

I understand; I too have mixed feelings about signed extensions. It certainly helps users have confidence in who developed the add-on and whether it's been modified, but taken to extremes, it just becomes another closed ecosystem, like the Apple store.

(There's also an implied promise: if, say, MCP signs an add-on, the user is likely to believe that MCP has checked the add-on for malware and the like. I think Mozilla tries to do that, but it's probably beyond the means of a smaller organization like MCP.)

Probably the best approach would have been something similar to code-signing certificates. When you install an add-on, it would validate any signature, and the certificate used to sign it, and let you know who, if anyone, signed the add-in, and whether anything was amiss. But the certificates wouldn't have to come from Mozilla, MCP, or anyone in particular, so there's no implied guarantee; and the user would have final say on whether any add-on was allowed to run, so if you knew why a signature was invalid, you could override the check for that add-on and let it run anyway.

Share this post


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

When Basilisk was later ported to UXP Take 2 (now just UXP), the issue of id-less WEs resurfaced

because they ported PM27's XPIProvider and its friends to UXP, which made huge differences between their XPIProvider and official ones.

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