strict_min_version

[khlr]

AMO complains when I try to upload the 1.9.3 release:

Your add-on failed validation with 1 error.
Unknown "strict_min_version" 140.11.0 for Firefox

Why did you raise the bar, @tvdijen ? 318321e

[tvdijen]

No specific reason, just thinking a year-old version of Firefox would be a reasonable minimum..
Feel free to put it back to where it was

[tvdijen]

Apparently it's only accepting majors or wildcards.. 140.0 is a reasonable minimum according to Grok.
I hope it is accepted now; I just changed it

For reference; these are accepted values: https://addons.mozilla.org/api/v5/applications/firefox/
Sorry I got in your way

[tvdijen]

@khlr were you able to try again?

[khlr]

By the way, version 1.9.3 has been available in the Chrome Web Store for quite some time now:
https://chromewebstore.google.com/detail/saml-tracer/mpdajninpobndbfcldcmbpnnbhibjmch

From Mozilla I got this reply:

Your Extension SAML-tracer was manually reviewed by the Mozilla Add-ons team in an assessment performed on our own initiative of content that was submitted to Mozilla Add-ons.

Our review found that your content violates the following Mozilla policy or policies:

• Sources, specifically Third party library information missing: Your add-on includes a third-party library. Please provide the origin of the exact library version you were using and make sure you are using an exact copy of the original maintainer's release version. Established libraries must be included from their official source, in their original format without any modification (changing the file name does not matter). Please note that only stable releases are acceptable (not beta, pre, RC, dev etc) and that third party CDNs are not considered official sources. For more information, refer to https://extensionworkshop.com/documentation/publish/third-party-library-usage/

• Sources, specifically Third party library not matching original: Third-party libraries or frameworks must be included from their official sources, in their original format without any modifications (other than changing the file name, if desired). Only release versions may be used and third party CDNs are not considered official sources. For more information, please refer to our third-party library guidelines https://extensionworkshop.com/documentation/publish/third-party-library-usage/ .

-> lib\pako_inflate.min.js
-> lib\highlight.min.js.

When I uploaded the release to AMO I noticed that our lib-folder was empty.
Shouldn't our build release workflow clone the both dependency and include the results? Seems not to happen.

I downloaded the min-js-files from the both repos and included them by hand in the zip-file to be uploaded to AMO.
The problem now is that, to be honest, I don't know how to cite the sources in a way that AMO would accept: https://extensionworkshop.com/documentation/publish/third-party-library-usage/

[tvdijen]

When I uploaded the release to AMO I noticed that our lib-folder was empty.

That's strange, because the build-logs clearly mention the files being added to the archive.
https://github.com/simplesamlphp/SAML-tracer/actions/runs/26720953604/job/78747797608#step:5:251

Let's keep an eye on this for the next release.

The problem now is that, to be honest, I don't know how to cite the sources in a way that AMO would accept

I would write that the sources and version numbers are cited in bin/script.sh.. Both dependencies do not publish their .min.js files anywhere, so we cannot reference them.

If they still don't accept it, we could try again to collect them as NPM Packages, but I remember we couldn't get that working last time I tried. Perhaps leave your email address so they can tell us what an acceptable solution would be for them?

[khlr]

Oh man... When I finished our version 1.9.3, there hadn’t been any new releases for either of those dependencies for ages. Guess what’s happened in the last few weeks... Both hljs and pako have had new (major) releases.

Both dependencies do not publish their .min.js files anywhere, so we cannot reference them.

I’ve just noticed that hljs has its own cdn-release repository, which hosts minified versions: https://github.com/highlightjs/cdn-release/tree/11.11.1/build
So we could take highlight.min.js, xml.min.js, properties.min.js and http.min.js from there instead of building it ourselves with node.js.
But guess what? While hljs 11.11.2 has been released two weeks ago there's no 11.11.2 cdn-build yet. Maybe they'll post a related release there in the next few days...

While creating our release I checked that pako's latest release was still 2.1.0 from 2022. In the meantime they released a version 2.2.0 (two weeks ago) and even a new major version: 3.0.0.
pako's documentation is rather sparse... I have no idea what has changed from 2.1.0 to 2.2.0 or 3.0.0.
But I noticed that there's a dist-folder in version 2.2.0 which unfortunately has vanished in version 3.0.0.
So again we could take a pre-built minified file from there as well (at least for version 2.2.0). I think this would be totally fine, if we found out that there's no actual need for using version 3.0.0.

Even though this topic is a bit annoying right now, it could be a nice opportunity for us to dramatically simplify our build.sh. So, what do you think about completely removing the cloning and building of the two projects, @tvdijen?

[tvdijen]

Yeah, I noticed the new releases too!
I was trying to remember why we do what we do, and I think it's mostly pako that has a lot more js-files than just the one file we use.

I'm totally fine with simplifying! We could drop the build.sh script and download the files from the build-release-action
All I can tell is that the removal of pako's dist-directory was a deliberate change that was mentioned in the changelog

[tvdijen]

I'm not sure what the best strategy is here.. It might be a dual strategy:

• highlight.js we can install using composer to fetch the .min.js file and they would probably accept that at AMO because the source is clear from the composer.json. It is also available through npm, but then there is no .min.js and I'm not sure how we would load it then.
• Pako cannot be installed this way, but it can be installed using npm to get the .min.js file. AMO can check the package.json file, so I believe they should accept that.

You have a better idea?

[khlr]

What about just something like this?

- name: Download pako
  run: |
    mkdir -p lib
    curl -L \
      https://raw.githubusercontent.com/nodeca/pako/refs/tags/2.2.0/dist/pako_inflate.min.js \
      -o lib/pako.min.js

[tvdijen]

That's short-term, because as you have already noticed there is no dist-directory in 3.0.0 anymore.
I also believe that AMO wants clear dependencies from a package-tool, not some reference in a script or a workflow..

[kellenmurphy]

Couple of thoughts here...

1. hljs publishes its cdn-release builds to npm as @highlightjs/cdn-assets, minified files included. We can pin it in package.json and copy the files verbatim. I think that'll help resolve AMO's requirement for an unmodified official artifact with clear provenance...

2. Also I'm wondering if pako can go away entirely. Native DecompressionStream('deflate-raw') can probably handle HTTP-Redirect binding's raw DEFLATE inflation... that's all it's used for, right?

I'm on holiday at the moment but happy to look deeper at either of these...

[tvdijen]

1. hljs publishes its cdn-release builds to npm as @highlightjs/cdn-assets, minified files included. We can pin it in package.json and copy the files verbatim. I think that'll help resolve AMO's requirement for an unmodified official artifact with clear provenance...

Yeah, no.. AMO says:

"You should download third-party libraries from their official site, not from a CDN or other location." as per the link @khlr provided earlier today.

Also I'm wondering if pako can go away entirely. Native DecompressionStream('deflate-raw') can probably handle HTTP-Redirect binding's raw DEFLATE inflation... that's all it's used for, right?

That would be a very nice simplification of this library!

Meanwhile I've created a PR (#110) that should make AMO a little bit more happy. I suggest @khlr tries to release v1.9.4 with this and we can further improve later.

[khlr]

I also believe that AMO wants clear dependencies from a package-tool, not some reference in a script or a workflow..

I think at the end of the day there's a manual reviewer who just compares file checksums.

While not to be confused with a CDN @highlightjs/cdn-assets is the official distribution for CDNs. Totally compliant to what AMO wants, I think:

You should download third-party libraries from their official site, not from a CDN or other location.

[...]

Communicating third-party library links to the reviewer:

You can add the links to the “Notes for Reviewers” section of your extension’s details on AMO.

And I'd really like to pick up Kellen's suggestion to drop pako in favor of DecompressionStream!

Meanwhile I've created a PR (#110) that should make AMO a little bit more happy.

I think that's a good intermediate step. I'll take a closer look at it right away.

--

I think that with the points mentioned above, we could achieve the following:

• Replace pako with DecompressionStream ➡️ external dependency removed
• Get hljs via @highlightjs/cdn-assets ➡️ Probably totally fine for AMO

This would also allow us to get rid of Composer right away after the intermediate step. In my opinion, Composer is a really heavy dev dependency that we (then) don’t actually need. What do you think?