diff --git a/.sync/nuxt-ui.json b/.sync/nuxt-ui.json index cc416c11..ff498a5c 100644 --- a/.sync/nuxt-ui.json +++ b/.sync/nuxt-ui.json @@ -1717,8 +1717,8 @@ "summary": "fix(SelectMenu): prevent search input focus on open with `autofocus: false` (nuxt/ui #6905) — PORT, verbatim. FocusScope trapped focuses the first focusable descendant when the menu opens, which is the search input, regardless of what searchInput.autofocus says — so :search-input=\"{ autofocus: false }\" had no effect on open and the virtual keyboard came up anyway on touch devices. Fix intercepts the scope's own event: onMountAutoFocus calls event.preventDefault() when searchInputProps.value.autofocus === false, bound as @mount-auto-focus on the FocusScope, plus a line on the searchInput prop doc and a ::note in the docs page. Our pre-image is upstream's — FocusScope trapped data-slot=\"focusScope\" with no handler, function onClear() immediately followed by const viewportRef = useTemplateRef('viewportRef') which is upstream's insertion point, and the docs page carries the same anchor paragraph with ### Content after it; only the standing ui -> b24ui class-binding rewrite applies (§1). The searchInput doc comment differs in its example ({ placeholder: 'Search...', type: 'text', size: 'md' } here against upstream's { placeholder: 'Search...', variant: 'none' }), a long-standing divergence, and the new sentence appends after it either way. TESTS COVER LESS THAN THEY LOOK, and that is the finding of this port. Upstream's two cases port structurally with one selector change — this fork puts data-slot=\"input\" on the control itself where upstream puts it on a wrapper, so [data-slot=\"input\"] input matches nothing here and becomes input[data-slot=\"input\"]; left as upstream wrote it the assertion fails on an empty wrapper rather than on the behaviour. The ported handler is NOT covered here and this was measured, not assumed: three mutations — removing @mount-auto-focus, inverting the condition to !== false, and calling preventDefault() unconditionally — all leave both tests green, and instrumenting onMountAutoFocus with a counter shows it called ZERO times, because reka's FocusScope does not emit mountAutoFocus under happy-dom. Read stage by stage, focus is BODY after mount, DIV[data-slot=root] after flushPromises, and INPUT[data-slot=input] only after a macrotask and only when autofocus is not false — so focus never lands on the input via FocusScope in this environment; it arrives from Input.vue's own autofocus, which is why upstream's symptom does not reproduce under happy-dom at all. The tests are not vacuous but guard a different thing: they pin the observable contract (searchInput: { autofocus: false } leaves the input unfocused on open) through the Input.vue path — verified by rewriting props.autofocus to true in Input.vue, which turns one of them red. The port is still right: in a real browser FocusScope does focus the first focusable descendant, so upstream's bug reproduces here too and the test environment merely cannot run that path; the handler is correct by construction and costs nothing. What is not claimed is coverage — the comment on the test block says so in as many words, so a later reader does not mistake green for verified." }, "12722057b3974acee4789f6a34aab05a18f6e835": { - "pr": "pending-merge", - "b24ui_sha": "pending-merge", + "pr": 534, + "b24ui_sha": "19fe6cdf252d5efec6e9d73935ca3da4cc24e989", "decision": "port", "summary": "docs: fix raw markdown served to agents (nuxt/ui #6914) — PORT, partial: the stringifier fix applies here, the nuxt-agent-discovery half does not. The reflex answer was a third skip and it would have been wrong. Its two predecessors on that line ARE skips — 9ef3ee39 built upstream's agent-discovery surface and ae243116 refactored it into the nuxt-agent-discovery module, neither of which this fork has — but reading the diff rather than the subject splits this one in two. Half is the module (bumping nuxt-agent-discovery ^0.1.1 -> ^0.4.0, deleting the prerenderRoutes() calls that fed it, moving its contentFilters), and none of that exists here. The other half fixes two defects in minimark/stringify, which THIS FORK USES TOO through the same call in docs/server/routes/raw/[...slug].md.get.ts: stringify({...page.body, type:'minimark'}, {format:'markdown/html'}). Both defects measured against our own installed minimark rather than inferred — a `table` node comes out as a literal block because the format has no pipe-table handler, and the `pre` handler always opens a three-backtick fence, so code carrying its own fences has the block CLOSED EARLY by the inner pair, leaving the rest as prose plus a second block. Not hypothetical here: docs/content/ carries markdown tables in 28 files and four-backtick fences in 7 (the typography pages documenting code blocks), and all of it reaches /raw/**.md, which is what skills/b24-ui-nuxt/references/components.md points agents at. Took docs/server/utils/markdown.ts as upstream wrote it (pipeTable renders a table node as GFM with each cell reduced to inline markdown; fencedBlock opens a fence longer than any run inside), adapting only its doc comment. Wired two passes plus a small replaceNodeWithMarkdown helper into transformMDC.ts — written against our file rather than applied as a patch, since ours is 1202 lines and diverges in its core (castMap rather than CAST_TEMPLATES, our own generateComponentCode, generateThemeConfig, convertIcon, processLinks); upstream's other additions in the same commit (KBD_LABELS, DROPPED_INLINE, the code-preview template reconstruction) belong to its own MDC vocabulary and were left alone. THE ORDERING IS LOAD-BEARING HERE AND IS NOT UPSTREAM: upstream absolutises links after stringifying, inside nuxt-agent-discovery, so its table pass can sit anywhere, while ours does it on the tree — processLinks walks the nodes and rewrites a.href in place — and pipeTable flattens an `a` node into [text](href) TEXT. Render the tables first and the hrefs inside their cells are strings by the time processLinks looks for nodes, left relative and pointing nowhere from a raw markdown file served to an agent. Both passes therefore run after processLinks, with the reason at the call site, and it is confirmed in built output rather than argued: a generated cell reads [TanStack Virtual](https://tanstack.com/virtual/latest/docs/api/virtualizer), rendered as a link and absolute. Verified by pnpm docs:generate and reading docs/.output/public/raw — 171 raw files, 30 now carrying pipe tables, zero raw
markup remaining (the one
left in the tree is prose, the Table page's note that the component supports all native
HTML attributes), fences longer than three backticks where the source needs them, and pipes inside code spans escaped as `Ref \\| undefined`, which without the escape would split one cell into two and shift the row. Tests: test/utils/raw-markdown.spec.ts, twelve cases, running against the REAL stringify rather than a description of it — two of them assert the PREMISE (that minimark writes a table as HTML and breaks out of a self-fencing block) so that if the dependency grows a table handler the workaround is reported as dead weight instead of quietly staying wrong. Five mutations verified, each failing its own assertion: fixing the fence at three backticks (3 red), dropping the pipe escape in a code span, collapsing a link to its text, not padding a short row, and dropping the header separator." }