Repository navigation
Docs stills from the film kit, and retire the old captures that showed home paths - #393
Merged
Merged
Conversation
…me paths Every feature page's still and every figure in the launch post (en/ja/zh) is now shot by films/doc-stills.mjs on the Shop demo, in the same isolated editor as the films. The 20 old PNG captures, which showed another product's name and a home directory in the Profiler panel, are deleted: no page used them, but the site still served them. - Each still is a 2400px WebP with width, height and alt text that describes the frame in the page's language; the launch post's captions now match their frames. - The kit: a film may publish stills alone, into its own screenshots folder; a still can keep a hover open; workbench dialogs (window.dialogStyle custom) let reopen answer the save prompt, and it fails if an edited editor survives. - SCREENSHOT-FIX-PLAN.md is complete (hover, diagnostics and definition are shown working, the pages are live) and is deleted.
MelbourneDeveloper
enabled auto-merge (squash)
October 18, 2026 13:51
MelbourneDeveloper
added a commit
that referenced
this pull request
Oct 19, 2026
## TLDR Website films play in Windows Chrome and Edge again: every video lists its H.264 MP4 before its VP9 WebM, and a new playback test proves frames actually decode. ## Details - **Root cause.** Windows Chrome/Edge accept the VP9 `<source>`, decode one frame, then stop with `PIPELINE_ERROR_DECODE`, and never try the next source. Every film listed WebM first, so every film failed there. - **`src/_data/videos.json`**: all 18 films now list `["mp4", "webm"]`. - **`video-figure.js`**: the VideoObject `contentUrl` points to the first (preferred) encoding instead of the last, so search engines link the MP4. - **New `tests/video-playback.spec.js`**: plays 20 films across docs and blog pages, then pauses, seeks to the middle and resumes. Each step checks that the clock advances, frames decode (`getVideoPlaybackQuality().totalVideoFrames`) and `video.error` stays null. A served file and a resolved `play()` don't prove playback. - **`tests/media.js`**: a new `expectFramesAdvance` helper, which also catches decode errors raised after `play()` resolves. - **`playwright.config.js`**: on Windows, the playback spec also runs on installed Chrome and Edge, where the bug reproduced; bundled Chromium and WebKit passed. The phone projects use installed Chrome there because Windows WebKit rejects known-good H.264. - **`docs/specs/DESIGN-SYSTEM.md` [WEB-DESIGN-MEDIA]** records the MP4-first rule and the playback-test requirement. - **Test expectations** in `profiler-media.spec.js` and `site-videos.spec.js` now expect MP4 first. - **Branch housekeeping.** This branch also merges the stale branches `feature/narrated-doc-films`, `feature/doc-stills` and `fix/382-netfx-review-findings` (all already squash-merged as #392, #393 and #385), plus `dependabot-upgrades`. None of them changes any file against main: - main already had every bump except TypeScript 7, which typescript-eslint 8.72 does not support yet (peer range `<6.1.0`); - the `lspkit` pin stays on lspkit `main` (`ccc59bf`). ## How Do The Automated Tests Prove It Works? - **`video-playback.spec.js`**: one test per film, named `<route> video <n> decodes, pauses, seeks and resumes`. It runs on Chromium, iPhone SE and iPhone 14 everywhere, and on Windows also on installed `chrome` and `msedge`. Each film must: - advance more than 1s and decode more than 5 new frames with `error === null`; - stay put while paused, so `currentTime` is unchanged after 250ms; - advance and decode again after seeking to `duration / 2`. - **`site-videos.spec.js` › `expectDescribed`** asserts the VideoObject `contentUrl` is the first listed source. - **`profiler-media.spec.js`** asserts the hero film's `<source>` order is MP4 then WebM. - **The full website Playwright suite (`make _test-website`)** passes locally, and Deslop reports 6.5% against the 6.65% threshold. --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
TLDR
Every docs feature page and the launch post now show stills shot by the film kit. The 20 old captures, some showing a home directory, are deleted from the site.
Details
src/website/src/assets/screenshots/docs/*.webp, 18 files).films/doc-stills.mjsshoots them ondemos/Shop.slnxin the same isolated editor as the films:sharplsp.toml;<img>withwidth="2400" height="1500"and alt text that describes the frame in the page's language.src/website/src/assets/screenshots/. Eleventy still published them, and the hover capture's Profiler panel showed/Users/<name>/…paths and the old "Forge" name. Also deleted:docs/plans/SCREENSHOT-FIX-PLAN.md, now complete.film.mjspublishes a film's stills intoscreenshots/<stillsFolder>(defaultprofiler), and a film with no clips publishes stills alone.still(…, { hovering })keeps a hover open.window.dialogStyle: customputs the save prompt in the workbench.reopennow answers it with "Don't Save" by role, and fails if an edited editor survives; before, a native prompt silently kept stale edits.showLogandhidePanelmove intokit/acts/language.mjs;configurationTomlis exported for reuse.[WEB-DESIGN-MEDIA]Capture now says no page shows a capture from any other source.How Do The Automated Tests Prove It Works?
screenshots.spec.js›Docs stills, new: for each of the 10 pages in en, ja and zh, the page shows exactly onescreenshots/docs/still, the expected file, withwidth/heightset, loaded at 2400px with real alt text (expectStills). For/blog/introducing-sharplsp/in each language: twelve current stills, all loaded at full size with alt text, and no.pngcapture left.expectStillsmoves fromprofiler-media.spec.jsto the sharedmedia.js, unchanged, so the profiler stills and the docs stills are checked by one helper.npx playwright testlocally: 703 passed, 11 skipped (by layout).deslop .: 6.5% (threshold 6.65%).