chore(main): release devbar 1.18.3

.release-please-manifest.json

@@ -1,4 +1,4 @@
 {
   "packages/sweetlink": "1.26.4",
-  "packages/devbar": "1.18.2"
+  "packages/devbar": "1.18.3"
 }

packages/devbar/CHANGELOG.md

@@ -1,5 +1,12 @@
 # Changelog
 
+## [1.18.3](https://github.com/ytspar/devbar/compare/devbar-v1.18.2...devbar-v1.18.3) (2026-07-17)
+
+
+### Bug Fixes
+
+* **devbar:** retry badge-hide injection for quiescent captures ([#35](https://github.com/ytspar/devbar/issues/35)) ([fc8bb93](https://github.com/ytspar/devbar/commit/fc8bb93f6ed1503c48a9bbd43deb85e413153cd8))
+
 ## [1.18.2](https://github.com/ytspar/devbar/compare/devbar-v1.18.1...devbar-v1.18.2) (2026-07-17)
 
 

packages/devbar/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ytspar/devbar",
-  "version": "1.18.2",
+  "version": "1.18.3",
   "type": "module",
   "private": false,
   "description": "Development toolbar and utilities with Sweetlink integration - pure vanilla JS, no framework dependencies",

packages/playground/src/release-notes.json

@@ -1,5 +1,6 @@
 {
   "devbar": {
+    "1.18.3": "Retry the badge-hide shadow-root injection for quiescent captures (DEV-6497). `suppressFrameworkDevIndicators` dropped its injection when the `nextjs-portal` element was present but its shadow root had not attached yet: the light-DOM MutationObserver sees the portal insertion (shadow still null) but never the later shadow attach — a shadow-DOM mutation it cannot observe — so on a *quiescent* captured page (no further mutations to self-heal) the resting Next.js badge leaked into the screenshot, the exact failure the badge-hide prevents. It now retries for a bounded number of animation frames (`setTimeout` fallback) when the portal is present but its shadow root is not ready, then gives up so a never-attaching portal cannot spin forever.",
     "1.18.2": "Hide the framework's own floating dev indicator (the Next.js dev-tools \"N\" badge) while it is benign — but never while it is signalling an error. Next renders the badge inside a `nextjs-portal` **shadow root**, fixed to a bottom corner; at rest it duplicates the devbar, sits on top of page content, and pollutes screenshots — and shadow-DOM encapsulation means no capture pipeline can hide it from the outside (a main-document `<style>` or html2canvas `ignoreElements` never reaches into the portal's shadow root). The devbar now injects a hide rule INTO that shadow root on init (`suppressFrameworkDevIndicators`, watching for the portal to (re)mount), so every capture backend — agent-browser, sweetlink CDP/CLI, html2canvas — sees the resting badge hidden. The rule is scoped to `[data-next-badge][data-error=\"false\"]`, so an **errored** badge (`data-error=\"true\"`) stays fully visible: a capture that shows it is telling you the captured page is broken, and hiding that would mask a real defect. `data-error` is live, so the CSS reacts on its own as errors come and go; the `[data-nextjs-dialog-overlay]` error overlay is likewise untouched. Cleaned up on `destroy()`.",
     "1.18.1": "Fix a leaked recording render-interval and a stuck record button (DEV-4874). The `record-start-response` handler now clears the timer the click handler started optimistically before starting its own (the first interval previously leaked and re-rendered forever) and rolls back the optimistic “recording” UI when the daemon reports the start failed. The Sweetlink WS record proxy now forwards `record-start` params (label/viewport) to the daemon instead of dropping them.",
     "1.18.0": "**Security (DEV-4521):** remote `exec-js` over the Sweetlink WebSocket is now OFF by default. The WS has no origin/auth model, so honoring `exec-js` unconditionally was an unauthenticated RCE — any local process (or any page that can reach `ws://localhost:<port>`, which is not gated by same-origin policy) could run arbitrary code in the host page. By default `exec-js` is refused and arbitrary `query-dom` property reflection falls back to the safe summary; the daemon's screenshot/recording/outline/schema/a11y features are unaffected. Opt back in with `initGlobalDevBar({ sweetlink: { allowRemoteExec: true } })` only when you trust everything that can reach the WS port. **Note:** if you rely on `sweetlink exec --js` against the browser, set `allowRemoteExec: true`.",