Can't install on Serpent

[martok]

Originally posted by @NEO-SPECTRUMAN in https://github.com/martok/palefill/issues/20#issuecomment-1153840901

We define the supported versions for Basilisk/Iceweasel-UXP as:

        <em:minVersion>52.9.2020.10.05</em:minVersion>
        <em:maxVersion>52.9.*</em:maxVersion>

Yeah, that can't work. Serpent reports itself as "52.9.0", ".0" being less than ".2020" causes that to be rejected. The generic toolkit version is never checked if an explicit definition with the matching UUID exists, can't save us here.

So there is at least a third version format using the same browser UUID (see 17c39efdc6a for the other two).

@roytam1 @g4jc Anything in particular I should be aware of or is it okay to just the minVersion to 52.9.0 and be done with it? IIRC Basilisk has a much longer history than 2020.10.05, what was the reason for that particular version?

[g4jc]

@martok I believe that the minver was arbitrary since it was likely the oldest version @JustOff may have been testing at the time. The Basilisk binaries don't even go back that far anymore, so for all intents and purposes I'm sure using 52.9.0 would be OK. If any users give you trouble about a specific issue with Iceweasel-UXP (which shouldn't be a large number of users since it's only officially supported on Hyperbola) they can use our tracker.

[Vangelis66]

Basilisk has a much longer history than 2020.10.05, what was the reason for that particular version?

I believe that the minver was arbitrary since it was likely the oldest version @JustOff may have been testing at the time

JustOff added official Basilisk support to gh-wc-polyfill just a short while after its initial commit, at the request of Moonchild himself (at a time when the rift between them wasn't that wide 😉 ...); see:

https://github.com/JustOff/github-wc-polyfill/issues/1, "closed" by https://github.com/JustOff/github-wc-polyfill/commit/4c271e220d5f09a3f8163b9df92012de3097507d

That was on Oct 16th 2020, just eleven days after the 2020.10.05 release... IOW, gh-wc-polyfill wasn't available to Bk versions prior to 2020.10.05; thus, not "arbitrary", but rather coincidental... 😄

[Vangelis66]

I'm sorry for posting a possibly OT comment here 😄 (but, from my point of view, it's still relevant - though, the now locked, https://github.com/martok/palefill/issues/20 would seem a more appropriate place to post this 😉 ), but @roytam1's New Moon 28 (Pale Moon) fork currently suffers from the same predicament this issue referenced for Serpent 52.9.0...

While NM28's platform version is 4.8.5, thus already covered by the "Generic UXP" targetApplication block inside palefill's install.rdf file, NM28 and PM share the same GUID and

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

disallows installation in NM28, which currently is @appVersion = 28.10.6a1.

Honestly though, I wouldn't know how to tackle that discrepancy myself; official Pale Moon 28.10.0 (assuming someone has been stuck at that an outdated version) is too old and devoid of native WebAPIs to support the correct functioning of palefill (and similar extensions); OTOH, the fork's maintainer has his own reasons for sticking to NM28's version numbering...

[martok]

If you really want to hijack an issue, this here is definitely a better place than #20 - as soon as there is a UUID match, the toolkit match does not apply.

The origin of 28.14.0 here is the exact same as the Basilisk version: I inherited the install.rdf from github-wc-polyfill where that was just the current version at the time of project start (Oct 2020).

official Pale Moon 28.10.0 (assuming someone has been stuck at that an outdated version) is too old and devoid of native WebAPIs to support the correct functioning of palefill

Not really: yes, a lot is missing, but not much more than in 28.14. The only two major things I see in the release notes are node.getRootNode and Object.fromEntries. We polyfill the first and don't use the second, so going back does not break anything that wasn't broken before. I don't see a problem with reducing the minVersion to the minor NewMoon uses.

[Vangelis66]

Thanks for this latest accommodation! 🎉

Not really: yes, a lot is missing, but not much more than in 28.14. The only two major things I see in the release notes are node.getRootNode and Object.fromEntries. We polyfill the first and don't use the second,

It is my experience that the abortAPI is also needed for certain GitHub functions (e.g. the "Preview" tab in comment editor 😜 ), and that was natively implemented in Pale Moon with v28.11.0 (2020-07-14) ... Again, this is only "academic" now... 😸

[martok]

Now imagine if you had actually taken the time to write a good bug report with that information instead of just dropping a screenshot into a random issue and leaving me to guess what the problem could be. I might have accommodated that.

In any case, 27 is way too old for Palefill to be useful. Pretty sure we even use JS syntax that it didn't have yet. Firefox 45 is (mostly) Firefox and I'm not opening that can of worms.

[Vangelis66]

@NEO-SPECTRUMAN:

... You can't seriously expect palefill to support the whole range of Roytam1 browsers, do you? You can probably forget about both New Moon 27 (Tycho[FirefoxESR 38]-based) and the fork of FxESR 45, because these two have very antiquated platforms, that can't, in all honesty, be easily made compatible with this extension... These two browsers are provided by Roytam1 as a courtesy to WinXP users with very old H/W (CPUs that have support up to the SSE instruction set, not higher), but even for such archaic H/W Roytam1 does provide special builds of his UXP browsers, i.e. New Moon 28 and Serpent 52, that the extension has been now made (in v1.13) compatible with... 👍 So, for GH/GL etc., use one of the UXP forks...

Serpent 55 is a very unique case, forked initially from a now abandoned MCP platform called Moebius, but recently that fork was more-or-less synced with UXP (roytam1's tree), so if you want support in that too, take the small bother 😉 of manually increasing the maxVersion to 55.0.0 inside install.rdf:

    <!-- Basilisk / Iceweasel-UXP / Serpent 52+55 -->
    <em:targetApplication>
      <Description>
        <em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
        <em:minVersion>52.9.0</em:minVersion>
        <em:maxVersion>55.0.0</em:maxVersion>
      </Description>
    </em:targetApplication>

@martok has been exceptionally magnanimous towards all of us, roytam1 browser users on Win < 7, so we shouldn't act "greedy", just thank him immensely for all the efforts he's been altruistically putting into this project, especially taking into consideration the "upstream" project (gh-wc-polyfill) has, once again, become orphant 😭 ...

Thank you Sebastian from the bottom of my ❤️ !

[martok]

Why you need this version blocking at all?

Because this is how extensions for Mozilla products have worked since that concept was invented.

No further discussion is required here.