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
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
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.