Jump to content

My Browser Builds (Part 3)


Recommended Posts

4 hours ago, Saphir said:

This one for example:

https://github.com/martok/palefill/releases - tried to install the latest version, and it failed. With Pale Moon 31 no issue.

In xpi-archive file install.rdf has to be modified:

<!-- Pale Moon -->
    <em:targetApplication>
      <Description>
        <em:id>{8de7fcbb-c55c-4fbe-bfc5-fc555c87dbc4}</em:id>
        <em:minVersion>28.14.0</em:minVersion>
        <em:maxVersion>31.*</em:maxVersion>
      </Description>

I lowered minVersion from 28.14.0 to 28.10.0 as I always do when installing polyfill add-ons. Now the add-on palefill 1.11 can be installed in NM28 and I tested new interface of VirusTotal. It works without setting dom.moduleScripts.enabled to false. Great! Big thanks to martok & co! :thumbup Of course, there might exist websites which don't work as expected. In palefill's options rules can be excluded. Simply try it!

Cheers, AstroSkipper ordi1fun.gif

Edited by AstroSkipper
addition
Link to comment
Share on other sites


@roytam1

Why are you not updating version number in your custom builds?

Your UXP version in term of features is like version 5.1.0.

The latest Serpent build is close to equivalent to the latest Basilisk in term of feature support.

A Plugin like palefilll uses the UXP version number to check features availability and apply fixes accordingly:

Commit (from yesterday): https://github.com/martok/palefill/commit/faf9a9267871b56c366eee5e7ce2ecb85541bca5

Also because of the minimum version requirements you need to manually edit the install.rdf file even for PM28 that is officially supported but version number increments slower on your builds so we are still to PM28.10.x even though it is closer to PM31 in term of web support.

There is probably a good reason for your version numbering system but I do not understand it.

I could make a fork of the palefill plugin to better support your UXP based browsers but I actually never wrote any plugins.

 

EDIT: actually modifying the plugin is trivial matter, I, just need to change 5.1.0 into 4.8.5 I will try that.

Edited by RamonUn
Link to comment
Share on other sites

1 hour ago, RamonUn said:

Why are you not updating version number in your custom builds?

Your UXP version in term of features is like version 5.1.0.

my tree is somewhat like 5.1.0 upstream, but not everything is the same as upstream.

there are lots of upstream changes are not included in my tree.

Edited by roytam1
Link to comment
Share on other sites

Ok, I understand.

Just to be sure then, In term of polyfill is there any difference?

UXP-5.1.0 supports: std-queueMicrotask, dhl-optchain and tmx-optchain.

From what I tested it seems 4.8.5 is good on those polyfill as well, and I think I can give the link to a modified palefill-1.11.xpi that supports NewMoon28, Serpent59, IceApe-UXP and BNavigator without overloading those on UXP-4.8.5+

here for people that are interested:

https://github.com/RamonUnch/palefill/releases

 

Link to comment
Share on other sites

2 hours ago, RamonUn said:

UXP-5.1.0 supports: std-queueMicrotask, dhl-optchain and tmx-optchain.

you may check BuildID to see if certain feature is available or not.

queueMicrotask: since 20220325000000

optchain: since 20220505000000

nullish coalescing: since 20220523000000

 

checking platform version from my builds can only distinguish if js-optchain and js nullish coalescing is really not available in platform code or not. (i.e. 4.8.4 or older don't have them, 4.8.5 may have them but depends on BuildID)

since those features are not available before I bump versions: https://github.com/roytam1/UXP/commits/9816e341b29ac8f3eb5223a6528197e88b381e22

Link to comment
Share on other sites

Rather than checking version numbers or build IDs, the ideal way for a polyfill to determine available JavaScript features would be to write some test code that tries to use the features in question.

But I'm not sure how practical that is. If you try to use, say, nullish coalescing and the browser doesn't support it, you get a syntax error. I don't think you can try ... catch a syntax error, so results of any test code are likely quite unpredictable.

So it may not be easy, or even possible, to do things the ideal way, and polyfill authors may be stuck checking version numbers or build IDs.

Link to comment
Share on other sites

Seems to be possible indeed:

https://stackoverflow.com/questions/23147087/how-to-detect-syntactical-features-of-javascript

In general it seems useless but in this case this is the way to go.

It would be the most practical thing indeed, I Just need too learn JavaScript at some point.

However for the UXP platform there are very few builds anyway so a version based system should be fine.

Link to comment
Share on other sites

On 6/4/2022 at 2:27 AM, roytam1 said:

New build of post-deprecated Serpent/moebius for XP!
...
Test binary:
Win32 http://o.rthost.win/basilisk/basilisk55-win32-git-20220604-ea6e33cd0-xpmod.7z
...
repo: https://github.com/roytam1/basilisk55
...
- import from nss upstream: Bug 1767590 - Initialize pointers passed to NSS_CMSDigestContext_FinishMultiple r=#nss-reviewers,kaie (118b893f8e) (ea6e33cd0)

That last commit, ea6e33cd0, is nowhere to be found currently in:
https://github.com/roytam1/basilisk55/commits/master

Was it simply forgotten to be properly committed in the GitHub repo or was it never included in the latest builds?
I attempted to load
https://github.com/roytam1/basilisk55/compare/c952169...ea6e33c
for a more detailed changelog between latest and previous builds (needed for a bug to be reported in a future post), only to be notified by GH that: 

"There isn’t anything to compare."

Link to comment
Share on other sites

1 hour ago, VistaLover said:

Was it simply forgotten to be properly committed in the GitHub repo or was it never included in the latest builds?

changes should be pushed now

Link to comment
Share on other sites

On 6/4/2022 at 5:59 PM, Saphir said:

After the last update to NM28 i am unable to install or update-add-ons, worked one build before

On 6/4/2022 at 7:30 PM, VistaLover said:

FWIW, in the latest UXP releases, there's at least one commit imported from upstream that deals with extension updates:

Issue #1909 - Guard against empty update manifest URL

Dearest @roytam1 :)

In a previous post of mine, I made a point that, apparently, was not given the full attention it deserved... So, I'll re-iterate:

Upstream (MCP) are currently further developing their platform (official UXP) with practically only one application in mind, i.e. official Pale Moon (the same can also be said about M.A.T. and his AuraRE platform, intended for his Borealis Navigator and Interlink applications). However, as things stand now, you also use your UXP-fork to build Serpent 52.9.0 (and several other forks, like the bin-oc+hyperbola ones), plus port UXP "patches" to Serpent 55/moebius...

While NM28 may have a closer connection to the official PM codebase, both St52+St55 have distinct differences to PM, likely to become wider in the future; thus, one must be very wary/careful of official UXP patches as to eventual detrimental effect(s) on St52 and/or St55 (we've had recent examples of that, with disabled GMP (EME) plugins (CDMs) and "pdf.js" in St52... :()

This very afternoon (despite the first heatwave - 37.5C/99.5F - :angry: of this summer....) I updated my St55 installation, from
"basilisk55-win32-git-20220528-c952169c0-xpmod" to
"basilisk55-win32-git-20220604-ea6e33cd0-xpmod"
(or was that, perhaps, "basilisk55-win32-git-20220604-5600fe37e-xpmod" ? ) ;
soon I discovered that the extension update feature was broken... :(

While official PM has the "Tycho" AOM (add-ons manager), both St52+St55 have a "WebEx" type one, because they do also support Web Extensions (à propos, St55's WE support has declined to St52's levels, what with the recent Sync with UXP, but this is material for a future bug report ;) ) ; also, in both browsers there exists the "extensions.update.background.url" pref, which can allow for setting up two different extension repos to watch out for add-on updates...

In my copy of St55, I have

extensions.update.url;https://versioncheck.addons.mozilla.org/update/VersionCheck.php?reqVersion=%REQ_VERSION%&id=%ITEM_ID%&version=%ITEM_VERSION%&maxAppVersion=%ITEM_MAXAPPVERSION%&status=%ITEM_STATUS%&appID=%APP_ID%&appVersion=53.0&appOS=%APP_OS%&appABI=%APP_ABI%&locale=%APP_LOCALE%&currentAppVersion=53.0&updateType=%UPDATE_TYPE%&compatMode=%COMPATIBILITY_MODE%

so that AMO would be monitored for updates of installed WEs, and

extensions.update.background.url;https://addons.basilisk-browser.org/?component=aus&reqVersion=%REQ_VERSION%&id=%ITEM_ID%&version=%ITEM_VERSION%&maxAppVersion=%ITEM_MAXAPPVERSION%&status=%ITEM_STATUS%&appID=%APP_ID%&appVersion=52.9.2022.01.27&appOS=%APP_OS%&appABI=%APP_ABI%&locale=%APP_LOCALE%&currentAppVersion=52.9.2022.01.27&updateType=%UPDATE_TYPE%&compatMode=%COMPATIBILITY_MODE%

so that ABBO would be monitored for eventual Basilisk XUL extensions updates (NB that, according to a MC statement I can't locate now in his forum, the ABBO repo may soon cease to exist...).

The above "arrangement" used to work as expected until (& including) build "basilisk55-win32-git-20220528-c952169c0-xpmod";
"about:addons => Check for Updates" will produce an alert (View Available Updates) for, at least, four suggested WE updates from AMO:

pobZChu.jpg

When moving on to "basilisk55-win32-git-20220604-ea6e33cd0-xpmod", "Check for Updates" stalls seemingly forever (being grayed-out), the AOM is in a permanent "Updating add-ons" state:

2ylztwh.jpg

The Browser Console is flooded with extension update manifest errors (for each checked extension), plus

19:22:10.249 1654446130246	addons.manager	WARN	Exception calling callback: ReferenceError: can't access lexical declaration `url' before initialization (resource://gre/modules/addons/XPIProvider.jsm:6686:1) JS Stack trace: UpdateChecker@XPIProvider.jsm:6686:1 < findUpdates@XPIProvider.jsm:7574:5 < doCommand/<@extensions.js:1168:15 < safeCall@AddonManager.jsm:191:5 < makeSafe/<@AddonManager.jsm:206:25 < process@Promise-backend.js:917:23 < walkerLoop@Promise-backend.js:801:7 < scheduleWalkerLoop/<@Promise-backend.js:737:11

I have verified locally that the culprit for this breakage is in fact:

ported from UXP: Issue #1909 - Guard against empty update manifest URL (7b3f9fb7)

"UXP: Issue #1909" shouldn't apply as-is on Serpent 52.9.0 and 55.0.0, because they have Extension Managers different to the one in official Pale Moon; so please, revert both

https://github.com/roytam1/basilisk55/commit/5600fe3 (for St55) and

https://github.com/roytam1/UXP/commit/7b3f9fb (for St52)

Thanks for understanding, best regards :)

Edited by VistaLover
Link to comment
Share on other sites

Link to comment
Share on other sites

On 6/7/2022 at 4:15 PM, roytam1 said:

... Without any justification in the commit message, if I might add... :angry:
But it's fallout from
https://repo.palemoon.org/MoonchildProductions/UXP/issues/1909

specifically read:

https://repo.palemoon.org/MoonchildProductions/UXP/issues/1909#issuecomment-30813

Since "we" are the first to be exposed to the "upstream" UXP master branch,
no wonder I was hit (and reported) that bug on "our" side of things...

Better watch out for the revised version of that (and eventual aftermath on the Serpent browsers),
if/when it makes it to upstream UXP...

Edited by VistaLover
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...