Repository navigation
Conversation
…entrance; WebKit shard flakes Every CI run since #52 spent 60-140 s more on the third WebKit shard than on the others (lane 202-284 s against about 140 s; the measured-time split predicts 134 s for each). The check-run annotations show why: two tests failed their first attempt there and passed on a retry. reveal-variant-browser (native mask and wipe: "must render intermediate frames"). The rAF clock that drives Reveal's mask, wipe and clock entrances without GSAP added the whole gap between frames. A probe that puts one 300 ms frame right after the start showed 0 frames in motion for mask and wipe in both WebKit and Chromium: a short entrance finished inside that one frame and the element simply appeared. Each frame now advances at most MAX_FRAME_STEP_MS (four 60 Hz frames, the limit frameEase() already used, now one named constant in src/utils.js), so the same probe shows 10 frames in motion. New case in tests/reveal-variant-browser.mjs: two 300 ms frames at the start of a native mask and wipe; fails on the old clock (0 frames), passes in Chromium, WebKit and Firefox. The sampling window also runs until every entrance has completed (at least 450 ms, at most 2.5 s), so a late start on a slow runner cannot read as "no motion" or "never finished". components-a11y tilt-rest waited a fixed 1.2 s, but the default smoothing needs about 1.05 s of 60 Hz frames to settle, so a runner that dropped frames still saw the tilt moving. It now waits for the rest (at most 4 s) and a failure reports how long after the last move frames were still requested. Verified in this container: the WebKit shard 11/11 in 2.2 min with no retry, the Chromium browser lane 48/48 with no retry, Node lane 65/65, lint. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FauCMhuVzQvUy2RZAXchUa
…er limit scan() finds every module of an engine tier with one selector made of all their [data-kt-*] attributes. jsdom 30 and later reject a selector longer than 2048 characters (browsers have no limit), so an app that registers enough modules of its own got a RangeError from autoInit() in its unit tests. Found while trying Dependabot's jsdom 30 bump (#7): tests/performance-runtime registers 100 modules, a 2.3 KB selector. queryAny() joins the attribute selectors up to the limit and starts another selector when the next one would pass it. The built-in registry (about 1.1 KB) is still one traversal. With several selectors, an element they share is collected once, and the union is put back in document order, so each module still creates its elements top to bottom. The test now emulates the limit on the root (querySelectorAll and matches throw past 2048): two traversals for 100 modules, every selector within the limit, and one element matched by two selectors created once per module, after the element before it. The old code fails it with the RangeError. The rest of #7 stays on hold: jsdom 30's CSSOM keeps background-position-x/y after removeProperty('background-position') (jsdom 29 and browsers remove them), which test:leak reports as a Scroll Shadows leftover. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FauCMhuVzQvUy2RZAXchUa
…en-panel Squircle measured the element once at create. Inside a hidden panel (a closed tab, accordion or dialog) the box is 0x0, so nothing was written, and only the polyfill path had a ResizeObserver: in Chromium, which draws with the native corner-shape property, a squircle in a hidden tab stayed a plain rectangle after the tab opened. The native path also wrote a percentage cornerRadius in pixels once, so it no longer matched the box after a resize. Both paths now observe the box; apply() already skips an unchanged box. tests/browser/squircle.mjs creates both paths inside display:none, shows the panel, and resizes a 50% radius. The old native path fails it (radius ""). scripts/audit-hidden-panel.mjs (npm run audit:hidden-panel) is how this was found: every module with demo markup is created visible, visible again, and inside display:none shown 80 ms later, and the script lists those whose layout boxes, node count or inline style differ only because they were created hidden. Modules whose two visible runs already differ are skipped, and understood differences are listed in one place with the reason. After the fix, 51 modules compare equal in Chromium, WebKit and Firefox. It is a tool for changes to how a module measures itself, not a CI gate (a few minutes per engine). Verified: squircle in Chromium, WebKit and Firefox; Node lane 65/65; the Chromium browser lane 48/48 with no retry; lint. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FauCMhuVzQvUy2RZAXchUa
…pens; audit --each Without GSAP (blocked or offline, or a data-saver device on the low performance tier) Reveal decides "in view" with an IntersectionObserver on the element, then measures the element without the transform it animates. A slide-left/right waits one whole element width aside. On a page that clips horizontal overflow (overflow-x: clip on html/body, common where things slide in), a wide card shows the observer only a sliver of that moved box, under the 10% threshold. Created while its panel was closed, the card got no further report when the panel opened (no scroll, no threshold crossing) and stayed at opacity 0 in Chromium, WebKit and Firefox. observeBoundaries() now also runs its check from a ResizeObserver, so the size change from 0x0 when the panel opens wakes it; the decision is still made on the unmoved box. (Widening the observer's root sideways was tried first and does nothing here: the html/body clip cuts the intersection before the root is applied.) The same check now resolves a percentage top/bottom rootMargin against the viewport height, as IntersectionObserver does; it used the width. tests/browser/reveal-hidden-panel.mjs (both browser lanes) blocks GSAP's CDN, creates a full-width slide-right and slide-left inside a closed panel on a clipping page, and opens it: the old code leaves both at opacity 0 after 3 s in all three engines, the fix plays them in about 420 ms. audit:hidden-panel gains --each (every distinct demo variant of a module, not only the first), which is how the two demo cards were found: 291 variants in Chromium, none differ after this fix. Verified: the new gate in Chromium, WebKit and Firefox (and failing on the old code in all three); Chromium browser lane 49/49 with no retry; the reveal/lifecycle subset in WebKit and Firefox; Node lane 65/65 (one retry of the Bootstrap integration's accordion reveal, which also flakes under load on the old code — it runs on the GSAP path, not the one changed here). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FauCMhuVzQvUy2RZAXchUa
…the tag v0.13.0 was tagged on a green commit, then the release workflow's all-lockfile audit failed on new undici advisories (GHSA-rfgv-xxqx-mfg5, GHSA-w293-vg96-wgc3 and eight lower) published after CI ran. Nothing reached npm and the tag cannot be moved, so 0.13 first ships as v0.13.1. - package-lock.json: undici 7.29.0 -> 7.30.0 (jsdom's ^7.25.0 range, dev only). audit:lockfiles reports 0 across all five lockfiles. - scripts/ship-release.mjs: after CI passes and before `git tag`, run scripts/audit-lockfiles.mjs; a failure stops with the version unused and says how to fix it. - tests/release-automation.mjs: the audit runs after the CI wait and before the tag, its failure message says no tag was created, and the release workflow still runs audit:lockfiles. - docs/RELEASING.md, CHANGELOG [Unreleased] (EN/KO: first-published 0.13 bullet, release:ship audit, undici), docs/QA_REPORT.md. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FauCMhuVzQvUy2RZAXchUa
The first published 0.13 release: why v0.13.0 did not publish, the pre-tag lockfile audit, and the hidden-panel / Reveal clock / jsdom 30 / WebKit shard fixes it carries. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FauCMhuVzQvUy2RZAXchUa
First published 0.13 release: v0.13.0 was tagged but its release audit failed on new undici advisories, so nothing reached npm (0.12.3 is still latest). Bumps every tracked version source, moves the bilingual Unreleased notes into [0.13.1], writes .github/release-notes/v0.13.1.md and regenerates the contract docs, builds, registry, MCP contract copies, module-cost and consumer bundle tables. Also: AI-HANDOFF records the version npm actually serves (0.12.3, seen with npm view) and that v0.13.0 never published; the QA section for this batch is labelled v0.13.1. Verified: npm run verify (lint, build, Node 65/65, demo QA, Chromium browser lane 49/49, pack, all-lockfile audit 0) and release:check. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FauCMhuVzQvUy2RZAXchUa
Read from the public annotations of PR #57's green CI (run 36633320041): - Every Node job (and the v0.13.0 Release verify job) carried a red "node_modules/.bin/attw exited with code 1" annotation. check-package-lint judges attw's JSON and ignores its exit code on purpose, but attw inherits NODE_OPTIONS and tests/ci-annotate.mjs reported its exit. scripts/gh-actions.mjs gains expectedExitEnv() (KT_CI_ANNOTATE=off) and failureAnnotationsEnabled(); the hook checks the latter and attw runs with the former. Old code: one ::error line with exit 0; new: none. Gate: tests/release-automation.mjs. - WebKit 2/3 slider-variant-browser: "dissolve did not settle at 1" with the slides frozen at 0.9811/0.0189 for 4 s, i.e. no frame ran. The waits (waitForLanding, transition) use __frameDeadline: give up once the time is up AND half of 60 Hz worth of frames ran, with a hard limit, and report frame count and longest gap. With a 4.3 s main-thread stall injected the old test fails at the first effect, the new one passes all ten. - WebKit 3/3 components-a11y sheet-close-button: read `hidden` after a fixed 150 ms; now polls with __until() (max 2 s) for the 40 ms close. Docs: troubleshooting (expectedExitEnv, frame-counted waits), CHANGELOG [Unreleased] EN/KO, QA_REPORT. Verified: lint, Node lane 65/65, slider and components tests in Chromium, WebKit and Firefox. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FauCMhuVzQvUy2RZAXchUa
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
…d at three points PR #58's CI (run 36645204708) failed WebKit 2/3 slider-variant-browser again with exactly the same numbers as PR #57's run: the incoming dissolve slide at progress 0.9811080386818688, i.e. 1 - 0.82^20 to all 16 digits (smoothing 0.18, twenty frames of exactly 16 ms). A random render stall cannot repeat a value, so this is a deterministic stop, and the previous commit's "no frame ran" reading was wrong. The track loop measured a frame as `Math.min(64, time - lastFrameTime)`: 0 for a repeated requestAnimationFrame timestamp, so a carousel fed the same timestamp stood still while still requesting frames. The radial loop compared `time` with performance.now() and could not finish either. Both now use frameClock() + frameEase() like every other following loop (a repeated or backward timestamp counts as one frame, one callback advances at most MAX_FRAME_STEP_MS). Gate: tests/browser/motion-timing.mjs feeds a track and a radial slider five normal frames and then 90 callbacks with the same timestamp; the old track stays at 80% (0.802). tests/motion-regressions.mjs's 60/120 Hz check now starts both runs with a callback at 1000 ms, since the first callback of a move counts as one 60 Hz frame at any refresh rate. slider-variant-browser's waits also report repeated rAF timestamps and page errors when they give up. stylize-patterns checks each motion at 250/450/650 ms: `flow` repeats every cell of travel (~390 ms) and dither-noise:flow failed two Firefox attempts on PR #58 with one sample at 650 ms; `none` must now hold still at all three. Docs: CHANGELOG [Unreleased] EN/KO (corrected), QA_REPORT 2026-09-30, troubleshooting. Verified: verify:push (lint, build, Node 65/65, demo QA, Chromium 49/49), motion-timing / slider-variant-browser / stylize-patterns / components-a11y in Chromium, WebKit and Firefox. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FauCMhuVzQvUy2RZAXchUa
catgarret
changed the title
catgarret
pushed a commit
that referenced
this pull request
Sep 30, 2026
… 1.2 s PR #59 CI (a3e652b) retried WebKit 1/3 flip-fold: all 12 pinned copies were still there 1.2 s after a 0.6 s change (their animations had not finished), and the retry passed. The check now polls until they are gone (at most 5 s) and reports how long that took; a copy that is never removed still fails. CHANGELOG [Unreleased] Tests bullet and QA_REPORT 2026-09-30 note the CI run (attw annotation gone, no Slider retry). Verified in Chromium, WebKit and Firefox. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FauCMhuVzQvUy2RZAXchUa
This branch has not been deployed
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
2 participants
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.
No description provided.