[dependabot]

Bumps @missing-elements/h5p-runtime from 1.0.0 to 1.0.1.

Release notes

Sourced from @​missing-elements/h5p-runtime's releases.

runtime 1.0.1, embed 1.5.0

@missing-elements/h5p-runtime 1.0.1 and @missing-elements/h5p-embed 1.5.0. The player stays at 1.4.0 and plays with runtime 1.0.1 as it is. The library pack, normalize, verify, author, cmi5 and the VS Code extension are unchanged.

Runtime 1.0.1

An Interactive Book reopens on the chapter the learner left (#127). With resume, a book came back with its answers but on its first chapter, in every resume mode and in SCORM packages. The book keeps its chapter under the content's id and takes it back only when the id matches, and the runtime gave the content a new random id on every load, as h5p-standalone did. The id is now a number made from the package's id, the same on every load of a package, as a site's content id is. Checked with a 12-chapter book in the player with resume="device" and as a SCORM package in Moodle 4.5 and SCORM Cloud: each reopened on the chapter the learner left.

Cornell Notes, which keeps a copy of its notes in the browser under the content's id and reads it only when the id is a number, finds that copy again too.

One consequence: two players of the same book on one page share the chapter in the page's address, so they turn pages together, as two copies of one content do on an H5P site.

Embed 1.5.0

The SCORM package reports each question's answer and keeps the learner's place in less room (#124).

• Each answer as a SCORM interaction, one per question: the question's words as its id, the type, the correct pattern, the learner's response, correct or wrong, the marks and the time taken. A retry writes over the question's record instead of adding one, so Moodle's interactions report keeps one column per question for every learner. Checked in Moodle 4.5, report included, and in SCORM Cloud.
• The saved state is compressed with lz-string 1.5.0 (MIT), which the zip and a written site now carry as lz-string.js. SCORM 1.2 keeps 4,096 characters: a quiz's state takes about 200, and a 12-chapter Interactive Book read to its end took about 1,000. A state written plain by an earlier version is still read.
• A save that cannot be kept is said. When a state does not fit, or the LMS refuses it, the learner sees one line under the content and the reason goes to the console; the last state that was kept stays, as before.
• The interaction count is read once, at launch (#130), so an LMS whose count does not follow what is written during a session cannot put every new question on one record.
• The page's notices sit in live regions that are there from the start, so screen readers announce them.
• buildScormInPage() takes the compressor as assets.lz. A page that bundles the launch files of 1.4 and gives no lz keeps working: it gets the compressor from base if it is there, or a zip without it that keeps the state plain, as 1.4 did.
• It requires runtime 1.0.1, so every package it writes carries the book fix.

Embed 1.4.0, the H5P-to-SCORM page (#122)

Published on 2026-11-03 without notes of its own. The SCORM package --scorm writes can be built in a browser, with nothing uploaded: buildScormInPage() from @missing-elements/h5p-embed/scorm/browser, startScormPage(), and scorm.html on every site the command writes. The demo has the page at https://h5p-offline-player.vercel.app/demo/scorm.html.

Upgrading

• A site that plays packages updates the runtime: a bundled site the package, a site that copied its dist/ copies it again, and one that loads it from jsDelivr through assets-base changes the URL to @missing-elements/h5p-runtime@1.0.1. The player and its Service Worker stay as they are.
• SCORM packages: run npx @missing-elements/h5p-embed@latest --scorm course.h5p on Node 22 or later, and replace the zip in the LMS. Where the LMS keeps a learner's state across the update, the new zip reads what an earlier zip of the same package saved.
• An embed site carries runtime 1.0.1 once it is written again and deployed.

Full Changelog: missing-elements/h5p-offline-player@v1.4.0...runtime-v1.0.1

v1.0.1

@missing-elements/h5p-offline-player 1.0.1 and @missing-elements/h5p-embed 1.0.1. The runtime, the libraries, the verifier, cmi5 and the normalizer stay at 1.0.0.

Fixed: the first load after upgrading to 1.0 (#49)

On a site a browser had visited before, upgrading from 0.10 to 1.0 could fail the first load, three ways. Each was reproduced with the published files and is fixed.

• A copy of the runtime kept from before. The runtime's files keep their names from one version to the next, and the demo and every site h5p-embed writes let a browser keep them for an hour. A returning browser ran 0.2's boot script under the new worker: "Cannot read properties of undefined (reading 'H5P')" on every play for that hour. The demo and the embed site now serve /frame-assets/ and /libraries/ with Cache-Control: no-cache, so the browser asks each time and gets a 304 when nothing changed. If you serve copied folders yourself, do the same; the README and docs/single-worker.md say how.
• Too short a wait for the new worker. The element waits three seconds for its updated worker and then goes ahead with the one it has. That is right within a major, whose older worker serves the element, and not across one. With h5p-sw.js answered after four seconds, the load went ahead with the 0.10 worker, the new one took over halfway through, and the load stayed in indexing. For a worker of another major the element now waits up to thirty seconds, and a load started during that wait waits on it too.
• A page still open from before the upgrade. The 1.0.0 notes said a tab still open on 0.10 keeps playing. On a host that serves the runtime at one path — the demo, an embed site, a copy of dist/ — it did not: the boot script at that path is 1.0's by then, and the next load stopped with "The player's Service Worker is older than this runtime". The worker now names the boot route in such a page's frame document too, and the 1.0 boot script boots from it.

A visitor who hit any of these only needs to reload: the new worker is active after the first failed load.

@missing-elements/h5p-embed 1.0.1

... (truncated)

Commits

• 28aa2f7 chore: update H5P player and runtime versions to 1.0.0 in documentation
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)