embed 1.3.1

@missing-elements/h5p-embed 1.3.1, with two fixes to --scorm. Nothing else changes: the player stays at 1.2.0, and the runtime and the libraries at 1.0.0.

SCORM Cloud imports the zips again (#92)

Every zip --scorm wrote from 1.2.0 to 1.3.0 failed to import in SCORM Cloud, with "IO Error processing zip". The package, the fonts and the library pack's parts are stored in the zip uncompressed, and the writer put their sizes after their data. Java's zip reader refuses that for an uncompressed entry, and SCORM Cloud reads uploads with it. 1.3.1 writes those sizes in front of the data, and still never holds the package in memory. Moodle and Frappe LMS read the zip's index instead, so they imported the older zips as they were. Other LMSs that read uploads with Java likely refused them too.

Checked in SCORM Cloud with zips from 1.3.1: the score, pass or fail, the time and the learner's place are recorded, and an export without its libraries plays from the parts in the zip.

ILIAS records the time of a session closed with the tab (#94)

The launch page saved the session's time, and that the session was left unfinished, as the page went away (pagehide). ILIAS sends what a closing page saves only during beforeunload, so a session the learner ended by closing the tab kept no time there. The score, the result and the learner's place were saved earlier, and were kept.

1.3.1 saves the time on beforeunload as well, and still ends the session as the page goes. So the content's own last save lands as before, and a learner who chooses to stay on the page keeps an open session. Moodle and SCORM Cloud record the same as before, and neither counts time twice.

Checked in more LMSs

The README now says what each LMS checked records:

• Moodle 4.5: the score as the grade, pass or fail, the time and the learner's place.
• Frappe LMS: the learner's place. It marks a lesson done only on a pass, keeps no score, and downloads the package whole rather than in ranges.
• SCORM Cloud: the score, pass or fail, the time and the learner's place.
• ILIAS 11: the same, once Learning Progress is on, which a fresh ILIAS has off. Turn it on in Administration, then choose "Collection of SCORM Items" in the module's Learning Progress settings and tick the item. Without it, ILIAS keeps the learner's place and drops every score and status.

Upgrading

• A SCORM package: write it again with npx @missing-elements/h5p-embed@latest --scorm course.h5p and replace it in the LMS. It needs Node 22 or later. Written from the same .h5p, it is the same build to the launch page, so learners' saved places still apply.
• An embed site: nothing changes.

Full Changelog: v1.2.0...embed-v1.3.1

v1.2.0

@missing-elements/h5p-offline-player 1.2.0, with @missing-elements/h5p-verify 1.4.0 and @missing-elements/h5p-embed 1.3.0. The runtime and the libraries stay at 1.0.0, cmi5 and normalize at 1.1.0. The VS Code extension's 0.2.0 is released separately, as h5p-preview-v0.2.0.

Content made for a newer library version plays on the newest older one

This changes a default. h5p.com gets a library's new minor version weeks before the H5P hub serves it, and the library pack follows the hub. So content made on h5p.com in those weeks can name a version no source has, such as Multiple Choice 1.17 where the pack has 1.16. Up to 1.1.2 the player refused such a package. When the newer version belonged to a part inside the content, such as a question in a Question Set, it booted the package instead and stopped with "Cannot read properties of undefined (reading 'on')", naming nothing.

Now, once every source in libraries has been tried for the version named, the content plays at the newest older minor of the same major that a source has, never across a major. A later source that has the version named still wins over an earlier one with an older version. A package that carries the newer version itself plays its own copy, trusted, as before.

Each library played older is listed in downgradedLibraries, on the element and in the ready event's detail, as { library, from, to }, and the console warns. downgrade-libraries="off" refuses such a package instead, naming the version it needs. That now covers a part inside the content too: its newer version is found before the frame boots, where it used to crash it.

Most minor versions only add fields, which the older code ignores. About one in four changes the shape of the content, which H5P marks with an upgrade step, and there a part can be missing or drawn wrong. Played untrusted, the content is still checked against the older version's fields. Content newer than the pack has the details.

@missing-elements/h5p-verify 1.4.0

The check plays such a package as the player does: it passes, with a warning for each library played older, and report.downgraded lists them. --no-downgrade-libraries, or downgradeLibraries: false in the API, fails it instead, and makes the preview refuse it too. Requires player 1.2.0.

@missing-elements/h5p-embed 1.3.0

The page passes &downgrade-libraries=off through to the element, and the report it posts to the embedding page on ready carries downgradedLibraries. Requires player 1.2.0, so a site written again plays such content. The SCORM writer stays strict: it refuses a package that needs a newer library than the pack has, when the zip is written, as before.

Upgrading

The change is in the element and the Service Worker, so update them together:

• On a CDN, change the player's URL to @missing-elements/h5p-offline-player@1.2.0 and copy its dist/h5p-sw.js onto your site again. The runtime's URL stays at 1.0.0.
• With a bundler, update @missing-elements/h5p-offline-player. The bundler emits the new workers.
• With your own Service Worker that mounts the player (mountH5P), build and deploy it again.
• With copied folders, copy dist/ again.
• An embed site: write it again with npx @missing-elements/h5p-embed@latest <folder> --force, and deploy it.
• A SCORM package needs nothing.
• The VS Code extension: update to 0.2.0.
• To keep refusing such packages, set downgrade-libraries="off" on the element, &downgrade-libraries=off in an embed page's address, or --no-downgrade-libraries on the verifier.

Full Changelog: v1.1.2...v1.2.0

H5P Preview 0.3.0

H5P Preview by Missing Elements 0.3.0, with player 1.2.0 inside, as in 0.2.0.

Install it from the Visual Studio Marketplace, or search for "H5P Preview" in VS Code's Extensions view. Cursor and VSCodium install it from Open VSX. h5p-preview-0.3.0.vsix below also installs with Extensions: Install from VSIX…. VS Code updates an installed 0.2.x by itself.

It says which video and audio VS Code cannot play

VS Code plays media with fewer codecs than a browser. Measured in VS Code 1.143 on macOS: an MP4's picture plays without its sound, M4A audio, WebM video and YouTube do not play at all, and MP3 plays with its sound. A package that lists a WebM first, such as h5p.org's Interactive Video example, showed "Video format not supported." where the MP4 beside it would have shown its picture.

0.3.0 reads the content once it is up, every slide and tab included, and says under the bar what VS Code will not play: "VS Code plays its MP4 video without sound and cannot play its WebM video." The line's Open in Browser button plays the package in your default browser, sound included. The extension cannot change VS Code's codecs. Windows and Linux are not measured. (#90)

Smaller

• The bar no longer shows a bare "U" for a package whose licence is undisclosed.

The .vsix attached is the one on Open VSX and on the Marketplace, built from 7de878e by the publish workflow (run 40938888472). SHA-256: d60e6057e981e812b7f646bccf671029e3ea41a06e998c1ba43fe3ac36af07c5.

H5P Preview 0.2.0

H5P Preview by Missing Elements 0.2.0, with player 1.2.0 inside. The npm packages' own release is v1.2.0.

Install it from the Visual Studio Marketplace, or search for "H5P Preview" in VS Code's Extensions view. Cursor and VSCodium install it from Open VSX. h5p-preview-0.2.0.vsix below also installs with Extensions: Install from VSIX…. VS Code updates an installed 0.1.x by itself.

Content made for a newer library version plays

h5p.com gets a library's new minor version weeks before the H5P hub serves it, and the library pack the extension carries follows the hub. So an h5p.com export from those weeks can name a version neither it nor the pack has, such as Multiple Choice 1.17 where the pack has 1.16. 0.1.x refused such a package, or, when the newer version belonged to a question inside it, showed nothing and an error.

0.2.0 plays it at the newest older minor of the same major, and the bar says so: "one library older than the content", its tooltip naming each one, "H5P.MultiChoice made for 1.17, played at 1.16.27". Most minor versions only add fields, which the older code ignores; where one changed the content's shape, a part can be missing or drawn wrong. A package that carries the newer version itself plays its own copy when played trusted, as before.

The .vsix attached is the one on Open VSX and on the Marketplace, built from ecbe452 by the publish workflow (run 40882900242). SHA-256: ceea9172c88e5f7f3a2466042ed98364538d716fccb791ceae43327f6d9b1396.

v1.1.2

@missing-elements/h5p-offline-player 1.1.2, with @missing-elements/h5p-embed 1.2.1 and @missing-elements/h5p-verify 1.3.1. The runtime, the libraries, cmi5 and normalize stay at 1.0.0. The VS Code extension's 0.1.1 is released separately, as h5p-preview-v0.1.1.

Vimeo videos play

The frame's policy let Vimeo's player API load, but refused the request that API makes before it creates the player: it reads the video's oEmbed record from vimeo.com/api/oembed.json. So every Vimeo video, in Interactive Video or a plain Video, waited eight seconds and ended in "loading error", in every mode and on every host.

The policy's connect-src now names that one endpoint, by path. Nothing else off the frame's origin is reachable from script.

Timeline loads its web media

Timeline fetches a slide's Wikipedia, Vimeo, SoundCloud and Flickr items as JSONP, that is, as scripts, and the policy refused them, so such a slide stayed empty. The four endpoints are now named by path, in both policies. Timeline's dead endpoints, Twitter, Storify, Vine and the YouTube feed, are not.

AR Scavenger is not supported

Found while checking the policy against every content type in the pack: AR Scavenger injects A-Frame and AR.js as inline scripts, which the frame's policy refuses, so it shows its title and no scene. It is not supported; Troubleshooting and the frame's CSP say why.

The element's API and the install paths have pages of their own

The README is shorter. The element's API holds the attributes, properties and events, and is the contract Compatibility holds a version to. Setting up the player has each install path in full.

@missing-elements/h5p-embed 1.2.1

Requires player 1.1.2, so a site written again, or a SCORM package written again, carries the fix. Nothing else changes.

@missing-elements/h5p-verify 1.3.1

Requires player 1.1.2, so npx runs the check and the preview with it. Nothing else changes.

Upgrading

The fix is in the Service Worker. The element and the Jobs worker change only in their version, so update them with it, and the versions match:

• On a CDN, change the player's URL to @missing-elements/h5p-offline-player@1.1.2 and copy its dist/h5p-sw.js onto your site again. The runtime's URL stays at 1.0.0.
• With a bundler, update @missing-elements/h5p-offline-player. The bundler emits the new workers.
• With your own Service Worker that mounts the player (mountH5P), build and deploy it again.
• With copied folders, copy dist/ again.
• An embed site: write it again with npx @missing-elements/h5p-embed@latest <folder> --force, and deploy it.
• A SCORM package: write it again with npx @missing-elements/h5p-embed@latest --scorm course.h5p and replace the zip in the LMS. Learners keep their place: the package's build stamp covers the package and its libraries, not the player.
• The VS Code extension: update to 0.1.1.

Full Changelog: v1.1.1...v1.1.2

verify 1.3.0

@missing-elements/h5p-verify 1.3.0. Nothing else changes: the player stays at 1.1.1, cmi5 at 1.1.0 and embed at 1.1.1.

A Download link on the preview page (#81, #82)

The page --preview opens has a Download link beside the package's name, so whoever reviews a package can keep the file they played. It takes the address the player is given, http or https only, and hides once the preview's server has gone, since that is where it downloads from.

The preview says when it has ended, and keeps saying it

When the command ended while the page was still opening the package, a state change or a failed request could write "Opening…" or an error over the page's "The preview has ended." line. That line now stays. CI caught it on main, where it failed 1 local run in 12; a test now sends the page those events itself.

The preview's module loads no Playwright

What the check and the preview share, the static server and the package and library helpers, moved from lib/verify.mjs to lib/serve.mjs, so lib/preview.mjs no longer imports the browser driver. The command is unchanged and still loads it for the check. The move is what lets the new VS Code extension, H5P Preview, bundle the preview's server without it. These modules are internal; the documented API does not change.

Upgrading

npx @missing-elements/h5p-verify@latest runs 1.3.0.

Full Changelog: verify-v1.2.1...verify-v1.3.0

H5P Preview 0.1.1

H5P Preview by Missing Elements 0.1.1, with player 1.1.2 inside. The npm packages' own release is v1.1.2.

Install it from the Visual Studio Marketplace, or search for "H5P Preview" in VS Code's Extensions view. Cursor and VSCodium install it from Open VSX. h5p-preview-0.1.1.vsix below also installs with Extensions: Install from VSIX…. VS Code updates an installed 0.1.0 by itself.

Vimeo videos play

The player inside 0.1.0 refused the request Vimeo's player makes before it starts, for the video's oEmbed record, so every Vimeo video ended in "loading error" after a few seconds. The frame's policy now admits that one request. Timeline's Wikipedia, Vimeo, SoundCloud and Flickr items load the same way.

AR Scavenger is not supported: it injects A-Frame and AR.js as inline scripts, which the policy refuses, so it shows its title and no scene. Troubleshooting says why.

The .vsix attached is the one on Open VSX and on the Marketplace, built from efc144c by the publish workflow (run 40776209479). SHA-256: c0836940ec90a496d340f640af5c76c664e9e3ad88870c9aa602c6d7c290f8a6.

H5P Preview 0.1.0

H5P Preview by Missing Elements 0.1.0, the first release of the VS Code extension (#83, #84). Nothing else changes: the npm packages stay as they are.

Install it from the Visual Studio Marketplace, or search for "H5P Preview" in VS Code's Extensions view. Cursor and VSCodium install it from Open VSX. h5p-preview-0.1.0.vsix below also installs with Extensions: Install from VSIX….

Click a .h5p and it plays

A .h5p file opens in an editor tab that plays it, in the same player a website runs it with: quizzes, interactive videos, presentations, every content type the H5P hub serves. There is no H5P server and no account. It works offline, and the package never leaves your computer.

• Exports without their libraries play too: the extension carries the libraries of every hub content type and supplies what a package lacks, with no network.
• It plays again when the file changes, so a package rebuilt by a script or an agent shows its new version.
• Open in Browser plays it in your default browser, served from this computer until you close the tab.

Packages you did not make

• Untrusted, a switch above the content, plays a package as a site plays one it did not make: none of its own code runs, its libraries come only from those the extension carries, and its content is checked against those libraries' semantics.
• In Restricted Mode every package plays untrusted.
• Newest libraries plays the extension's newer version of a library a package carries. Turn it off to see the package exactly as exported.

Requirements

VS Code 1.90 or later, on the desktop; VS Code for the Web cannot run the extension's local server. In a remote or virtual workspace, the extension runs on this computer and copies the file here before it plays.

The .vsix attached is the one on the Marketplace and on Open VSX, built by CI from c24ce55 (run 40668629428). SHA-256: df461d0592b465019e8f1daffeba1a0c27e906af231eb0d378eee61916e36321.

embed 1.2.0

@missing-elements/h5p-embed 1.2.0. Nothing else changes: the player stays at 1.1.1, the runtime and the libraries at 1.0.0.

A SCORM 1.2 package of one .h5p, for an LMS

npx @missing-elements/h5p-embed@latest --scorm course.h5p     # writes ./course.scorm.zip

--scorm writes one package as a SCORM 1.2 zip instead of a site: the package, the player and the H5P runtime, and a launch page that reports to the LMS. Add it to a course as a SCORM activity, in Moodle or another LMS that takes SCORM 1.2, and the LMS records:

• the score out of 100, and passed or failed when the content says whether it was passed, completed when it does not. The content's last result counts, as on an H5P site;
• the time spent in each session;
• the learner's place, in cmi.suspend_data, which the next launch continues from. SCORM 1.2 keeps 4,096 characters, enough for a quiz; a larger state is not saved.

The LMS keeps the results, so no server of yours is involved.

• Exports from h5p.com and h5p.org work. They leave the libraries out, so the zip carries the ones the package needs from the library pack, and only those: 11 libraries and 4 MB for a quiz with formulas. A package that carries its libraries plays with its own.
• A missing library is caught when the zip is written, not when a learner opens it. A package that needs a library neither it nor the pack has, or a newer version than the pack's, is refused, with what is missing named.
• Moodle records the score as the grade, out of the activity's maximum grade, so leave that at 100, its default.
• The LMS has to be served over https, since the player needs its Service Worker, and Moodle has to serve files by path (slasharguments), which it does by default.
• Content that reports no result of its own, an Accordion or a Virtual Tour, stays incomplete: complete such an activity on viewing it instead.
• Replacing the zip with one written from another .h5p, or with other libraries from the pack, starts learners over, since their saved state belongs to what it was saved in.
• The package plays trusted: its own code runs on the LMS's origin, as every SCORM package's does.

Checked in Moodle 4.5: the score reaches the gradebook, and a learner who leaves halfway continues there on the next launch. Other LMSs have not been tried yet.

A second argument names the zip, and --force replaces one already there. The site's own options, such as --packages, are refused with --scorm rather than ignored. For a script, buildScorm({ h5p, out, force }) from @missing-elements/h5p-embed/scorm writes the same zip and returns what it wrote, typed: its path, size and title, the player's version, the libraries taken from the pack, and the build a learner's saved state is kept against.

Also in 1.2.0: the NOTICE.txt a site is written with said both workers carry zip.js. Only the Service Worker, h5p-sw.js, does, and the notice now says so.

Upgrading

• A SCORM package: npx @missing-elements/h5p-embed@latest --scorm course.h5p runs 1.2.0. It needs Node 22 or later.
• An embed site: only its notice changes. Write it again with npx @missing-elements/h5p-embed@latest <folder> --force when you next deploy.

Full Changelog: verify-v1.2.0...embed-v1.2.0

verify 1.2.1

@missing-elements/h5p-verify 1.2.1. Nothing else changes: the player stays at 1.1.1, cmi5 at 1.1.0 and embed at 1.1.1.

Ctrl+C ends --preview with its closing line and exit code 0 when run through npx (#79)

Run through npx, as the docs show, one Ctrl+C reached the preview twice: the terminal sends it to the whole process group, and npm passes on its own copy. 1.2.0 stopped listening after the first, so the second killed it before it printed "The preview ended.", and it never exited with 0. The preview itself still stopped and freed its port.

The preview now listens for SIGINT and SIGTERM for as long as it runs, from before it prints its address. Measured with one Ctrl+C through npx, three runs each: 1.2.0 never printed the closing line and was killed by the signal; 1.2.1 printed it and exited with 0 every time.

An agent that leaves the preview to end when its tab closes sends no signal, and was not affected.

Upgrading

npx @missing-elements/h5p-verify@latest runs 1.2.1.

Full Changelog: verify-v1.2.0...verify-v1.2.1