#7 build(deps): bump @missing-elements/h5p-offline-player from 1.1.1 to 1.2.0

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

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: https://github.com/missing-elements/h5p-offline-player/compare/v1.1.2...v1.2.0

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

... (truncated)

• ecbe452 chore: update package versions to 1.3.0 for h5p-embed, 1.2.0 for h5p-offline-...
• 707dbb6 fix: report libraries played older on the load, not on the library bundle (#85)
• f2b33bf feat: play content made for a newer library minor than any source has, on the...
• efc144c chore: update package versions and improve troubleshooting documentation
• 2dab0a1 Refactor documentation and improve player functionality
• 3c6abde test: pace the early-boot pack test at 32 kB/s, so a slow runner has two seconds
• See full diff in compare view

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)