STACK: Update code for latest STACK API version and add feature testsuite example

[geoo89]

The official STACK API deployment was updated on 2026-07-16 with a security update: The API was retrieving plots and files directly from the server, and theoretically a user could submit a question containing a dodgy file and then access and run it. The update serves plots and files indirectly as STACK does normally, so the URL of these assets has changed.

This PR updates the JS client and static version generation for STACK questions to address this.

It also fixes a few more bugs in the JS version that we've encountered over time, and supports a few more STACK features. This is tested against a new example showcasing a variety of STACK questions (mostly test cases shipping with the official STACK library).

It appears that now the JS shipped with compiled HTML versions comes from js/dist, so there is one commit copying the effective changes to the STACK JS files into that folder.

Along the way we're now also generating extracted images in SVG and PNG formats. This fixes #3033.

Joint work with my colleague @murungadaniel and Claude.

[rbeezer]

@geoo89 - thanks for the recent PRs for STACK. Pretty much every contributor's contributions is now getting a first pass from Claude Pro. It is not just a totally automated thing, I use an initial review for a first look and what gets posted here is adjusted based on that. So not a full review, but not a complete robot either. Coming next.

[rbeezer]

Thanks for this — it's a substantial, carefully-explained piece of work, and the commit messages make the reasoning easy to follow. The security-relevant changes (dropping allow-same-origin on the srcdoc iframes, and routing postMessages by e.source rather than the self-reported msg.src) look correct and are a real improvement. A handful of requests before a merge:

1. Don't include the js/dist regeneration in the PR. Regenerating the bundles from js/… is a maintainer step (via the jsbuilder script), done at merge time. Committed js/dist changes create merge conflicts that are effectively unresolvable across PRs, so we keep them out of contributions. This is a newish convention, so no reason you'd have known it — please just drop the dist-regeneration commit and leave js/dist/pretext-stack/* untouched; I'll rebuild it when merging. (Your note that the previously-committed dist predated the source fixes is exactly why we now regenerate centrally.)

2. Please keep stackjsvle.js at its original indentation. The file has been wholesale reindented (4→2 spaces) and restructured, which makes the diff very large and buries the actual logic changes — and those changes are the security-sensitive parts that most need careful review. Can the indentation go back to what it was, so the diff shows just the behavioral deltas? We'd rather not have formatting churn like this land in one pass with substantive fixes.

3. pretext-html.xsl reinvents the existing id machinery. The new <xsl:attribute name="id"> with a hand-written @label/@xml:id <xsl:choose> duplicates the modal html-id template (and its convenience wrapper that builds the id attribute directly). Please use the existing mode instead of a bespoke choose — the surrounding code and other elements' id handling should make the pattern apparent. Beyond avoiding duplication, this guarantees the id here matches what the rest of the conversion generates when it references that id.

4. stack.py: use .format(), not f-strings. The added asset-download lines use f-strings (and carry stray trailing semicolons). Our Python convention is str.format() and no semicolons; the file already drifts here, but please normalize the new lines (and ideally the immediate neighbors you're touching).

5. Error message. The PTX:ERROR for a STACK question lacking @label/@xml:id is split across two <xsl:message> calls, so the second line logs without the PTX:ERROR prefix and reads as an orphan. Please emit it as a single message. (This becomes moot if #3 routes through html-id, which handles the id derivation itself — but worth fixing regardless.)

6. Example file header. examples/…/source/main.ptx opens with the old "Copyright 2015 … MathBook XML" boilerplate. For a new file please use the current PreTeXt header.

None of these are structural — the design is sound and the bug/security fixes are welcome. Mostly it's dropping the dist commit, reverting the reformat, and reusing the existing id template.

Claude Opus 4.8, acting as a review assistant for Rob Beezer

[rbeezer]

A force-push is always fine at junctures like this one - necessary changes thoughout a list of commits.

[geoo89]

I've amended some of the commits to address the issues above.

[rbeezer]

@geoo89 — a follow-up on point 6 (the file header), with an apology attached.

The intent of that point was to replace the old Copyright 2015 … MathBook XML boilerplate with the current PreTeXt header — but the amended commit removed the header entirely, so examples/stack/features/source/main.ptx now opens directly into <pretext> with no copyright/license block at all. For a new .ptx file we do want that block present, just in the current PreTeXt wording. You can copy it verbatim from a recent source file; examples/numbering/main.ptx is a good model:

<!--********************************************************************
Copyright 2026 Robert A. Beezer

This file is part of PreTeXt.

PreTeXt is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 2 or version 3 of the
License (at your option).

PreTeXt is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with PreTeXt.  If not, see <http://www.gnu.org/licenses/>.
*********************************************************************-->

(You'll notice some older files still say "MathBook XML" — that's a cleanup pending on our side, not the form to copy.)

And a genuine apology for the delay. When @rbeezer re-reviewed the force-pushed commits, the removed header was in fact caught and written up as a blocker — but that note was never actually posted, so it's only reaching you now, a week on. That lapse is entirely on us; sorry to have left it hanging, and thanks for your patience.

Claude Opus 4.8 (1M context), acting as a review assistant for Rob Beezer

[geoo89]

Thanks, I've added the new header and amended the first commit.

[rbeezer]

Re-reviewed from scratch at the current head. All six earlier requests are properly addressed — no js/dist in the diff, original indentation restored, the exercise/stack id now comes from the stock html-id-attribute mode (the only HTML delta on the existing stack/minimal example is that div gaining its id), every touched stack.py line uses str.format(), the split error message is gone along with the bespoke id code, and the header is the current form, verbatim. Beyond that: the sender-resolution design (e.source → WeakMap → internal keys, raw API id kept only for echoing) is sound and well-commented, the sandbox note explaining why allow-same-origin must never appear on a srcdoc iframe is exactly right, and the asset pipeline works live — a static generation of the testsuite's plot question against the Edinburgh server produced the SVG, the PDF conversion, and the 300-dpi PNG via the new plot.php path with the fallback intact.

Remaining items, mostly small:

1. The example doesn't validate. Two schema errors: frontmatter needs a <titlepage/> (before abstract), and ex-integration-knowl sits after the <exercises> division in subsec-formats, where a bare exercise is not allowed — move it ahead of the division (or inside it).
2. download()'s error path: the catch writes to document.getElementById('errors') — unprefixed, so no such element exists and the handler itself throws. Should be the question's ${qprefix}errors (qprefix is already a parameter).
3. Radio groups collide across questions. The send() rewrite prefixes id/for but not name, and radios with the same name and no form owner are one document-wide group. The testsuite itself exhibits this: Radio and Radio_compact both use ans1, so both render name="stackapi_input_ans1" on the same page — selecting in one deselects the other, and the deselected question then grades as unanswered. Simplest fix is probably a <form> per question shell in createQuestionBlocks (radio grouping is scoped to the form owner); prefixing names would also work but ripples into collectAnswer and the vle lookups.
4. vle_get_element lost its confinement. The Moodle original restricted lookups to the question's container; the new version returns any element on the page by id, so change-content/get-content/toggle-visibility from a question's iframes can now read or replace content anywhere, crossing the per-question isolation this PR otherwise establishes. Since every call site already knows the sender's key, confining to IFRAME_TO_BOUNDARY[key] looks straightforward.
5. The example cannot build from a fresh checkout: the publication file names source/directories/@generated="generated", and the build aborts when that directory is absent. Please ship examples/stack/features/source/generated/ in the PR — a .gitkeep file inside will let git track the otherwise-empty directory.
6. Prose: the article title has "differents" and "PreText" (→ "different", "PreTeXt"); "occured" → "occurred" in the introduction's issue list.
7. Hygiene: main.ptx has ~33 lines of trailing whitespace (the question .xml assets are upstream exports and fine as-is); there's one empty <p/> in subsec-inputs; publication/publication.ptx is a new file carrying "Copyright 2015" (main.ptx now says 2026); and baseurl href="https://example.url" is a placeholder that ends up in static-output fallback links.

One non-blocking observation, since you're well placed to carry it upstream: vle_html_sanitize removes attributes while iterating the live el.attributes collection, so the attribute immediately following a removed one is skipped — two adjacent event-handler attributes leave the second in place. That code is verbatim from the upstream Moodle stackjsvle.js, so it's a STACK matter rather than anything for this PR.

Claude Fable 5, acting as a review assistant for Rob Beezer

[geoo89]

I've addressed the comments above. 2, 3, and 4 are separate commits for transparency's sake while the other changes got squashed into the first commit that creates the article. I left the publication base URL placeholder as there is no live deployment to point to.

[rbeezer]

• We never put code comments into commit message bodies. And especially if the message body is longer than the commit itself. One line only. Please make sure that your procedures are not making bodies for commit messages ever. I have done the work to strip them out. Judging by their extent, I think some (most?) of their content should go into the code as code comments, and generally any explnation should run with the code itself. Please do that on a separate PR all by itself that will not cause merge conflicts.

• We just added a major cleanup to copyright notices, wo new files here need editing. I like to have README indicate when whole files come from somewhere else and their license status. There are one or two like this.

• Please indicate if some recent issues are can be closed by this (or subsequent PRs).

• I think Add CSS to STACK JS questions rendering #3044 is now ready for a tune-up before re-consideration.

[rbeezer]

Forgot to say: the reworked branch has been merged - so all new hashes, etc, but no real code changes

[rbeezer]

When you built teh sample article with -vv did you see:

* PTX:DEBUG: xref/@ref "introduction-structures" points to a "introduction" element.  (1) we made a mistake, and we need to add this element to a list of potential targets of a cross-reference, or (2) you made a mistake and really did not mean this particular construction, or (3) we need to have a discussion about the advisability of this element being a target.   (4) If you are trying to cross-reference a "p" element, perhaps using a "paragraphs" element is a good alternative.  If (1) or (3) could you please report me!

It is a weird situation. admittedly, but it needs to be addressed - the sample article should never be incorrect.