Jump to content

My Browser Builds (Part 1)


Recommended Posts

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

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

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

 

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

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

Link to comment
Share on other sites

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

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

Link to comment
Share on other sites

29 minutes ago, roytam1 said:

because they ported PM27's XPIProvider and its friends to UXP

Good morning! :) Is "PM27's XPIProvider and friends" what is referred to as TychoAM in the UXP GitHub repo? Was that change implemented early on in UXP development (I was under the impression WebExtAM was only removed towards the end of 2018/start of 2019, when WE support in Bk52 was obliterated :angry:)?

From a comment by Moonchild himself exactly a year ago:

https://forum.palemoon.org/viewtopic.php?p=141539#p141539

Quote

WebExtensions MUST have an extension ID if they are going to be compatible with UXP. It takes little effort on the extension dev's side to do so and saves us an architectural nightmare.

The extension dev can solve this by adding an ID.

https://forum.palemoon.org/viewtopic.php?p=141641#p141641

Quote

It's one of the few design choices that are different in Take2; we want to do things a little bit more organized and put down some ground rules to prevent as much of a mess as Mozilla has let the add-on scene turn into with its muddle of 4 technologies each with their own exceptions to established design.

Best regards :cool:

Link to comment
Share on other sites

On 5/23/2019 at 10:07 PM, Mathwiz said:

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;

... And while you were at it, you could have also used a slightly modified id string for Tab Tally 1.3.0 (or 1.2.0 etc.) for it to install in either Serpent 55.0.0 or Serpent 52.9.0:

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

St55 still contacts AMO to check for WE add-on updates, so, based on your settings, you'll be either upgraded automatically to v1.4.0 or be prompted to do so manually...

St52 currently doesn't check AMO for WE updates (due to MCP implemented changes), but this can be partially or fully restored (search one of my previous posts in this thread for how-to-do it ;)).

Installing Tab Tally with a different to the default extension id means you won't ever be offered any additional updates from AMO (and this is a known hack if one wants to stay at a specific version of an extension without having to disable extension updates in the browser)...

On 5/23/2019 at 10:07 PM, Mathwiz said:

of course changing manifest.json invalidates the sig, but unlike FF, Serpent doesn't care about that

... and that is why you can also remove the whole META-INF directory! :)

Edited by VistaLover
Link to comment
Share on other sites

On 5/22/2019 at 3:31 AM, 3dreal said:

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.

I use a Promise SATA300 TX2 Plus PCI SATA controller in my overclocked Tualatin RDD. Runs quite well, plus it supports AHCI and Native Command Queuing. Not bad for a Pentium 3!

By the way, I have updated the UOC Patch right now. Please download the newest version!

Thread link:

 

Edited by looking4awayout
Link to comment
Share on other sites

New build of Serpent/UXP for XP!

Test binary:
Win32 https://o.rths.cf/basilisk/basilisk52-g4.2.win32-git-20190525-315ffd563-xpmod.7z
Win64 https://o.rths.cf/basilisk/basilisk52-g4.2.win64-git-20190525-315ffd563-xpmod.7z

source code that is comparable to my current working tree is available here: https://github.com/roytam1/UXP/commits/custom

NM28XP build:
Win32 https://o.rths.cf/palemoon/palemoon-28.6.0a1.win32-git-20190525-315ffd563-xpmod.7z
Win64 https://o.rths.cf/palemoon/palemoon-28.6.0a1.win64-git-20190525-315ffd563-xpmod.7z

Official repo changes since my last build:
- Unhook Unboxed Objects option (3ded48cbe)
- remove unboxed code chunk (wip1) (9a3141515)
- Remove initial chunk of Unboxed Objects machinery part 2 (3b36a43e8)
- Remove Unboxed Objects in ScalarReplacement (d40bcc350)
- Remove unboxed objects from GC (5fd4b8726)
- Remove unboxed object code from iteration. (8feffe707)
- Remove array header (a5c2961c4)
- Remove Unboxed Objects from vm/ Part 1 + fix deprot (543fa1674)
- Remove unboxed object code from jit, Part 1 (fa8bfa1a0)
- Remove Unboxed Objects from vm/ - Part 2 (201d8ee48)
- Implement array.flat and array.flatMap (162e22a7d)
- Implement Symbol.prototype.description (41731a7f3)
- Issue #971 - Fix browser.link.open_newwindow functionality in Pale Moon (f9dc4e8cc)
- Merge pull request #1097 from FranklinDM/pm_external_sametab-work (a1f96f11d)
- Merge pull request #1091 from MoonchildProductions/remove-unboxed (be8d03cf1)
- Remove a stubbed telemetry function from app AUS. (bb5e0a1be)
- Enable double buffering when using XRENDER. (2fd300786)
- Merge pull request #1100 from Ionic/bugfix/xrender-flicker (372fccddf)
- Issue #1104 - Set the browser's opener when adding a new tab - This modifies `loadOneTab` and `addTab` to accept an opener - This code was adapted from Basilisk's copy of tabbrowser.xml without the refactored code changes (which is a lot more involved as it divides addTab's functions into multiple functions) (797697e26)
- Issue #1104 - Pass an opener to loadOneTab in the openURI function (10318170b)
- Issue #1101 - Support gzip-compressed SVGs in OpenType+SVG fonts (73f9b2c70)
- Merge pull request #1108 from g4jc/svg_opentype (f8157b8a6)
- Merge pull request #1105 from FranklinDM/pm_uri_tabbrowser-work (f0e357608)
- Merge pull request #1099 from adeshkp/remove-telemetry-func (315ffd563)

My changes since my last build:
- ported changes from mozilla upstream: bug1351303, bug1352235, bug1371508, bug1430268, bug1352734

Edited by roytam1
Link to comment
Share on other sites

New build of BOC/UXP for XP!

Test binary:
MailNews Win32 https://o.rths.cf/boc-uxp/mailnews.win32-20190525-86c9c06-uxp-315ffd563-xpmod.7z
Browser-only Suite Win32 https://o.rths.cf/boc-uxp/bnavigator.win32-20190525-86c9c06-uxp-315ffd563-xpmod.7z

source patch (excluding UXP): https://o.rths.cf/boc-uxp/boc-uxp-src-xpmod-20190223.7z

Official repo changes since my last build:
- [NAVIGATOR] Alter the background size so that it matches the grippy better on the main window (d9aa7ac)
- [PLATFORM] Update commit pointer (86c9c06)

For UXP changes please see above.

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