` slots (merge.length is > 0 by the time the end marker arrives, so the new branch's `!merge.length` guard short-circuits and case D still closes the merge as `'html'`). Verified against i18next-subliminal's `containsHiddenMeta` semantics (requires the trailing 9 chars to decode to `'}'`, so stray invisible chars from unrelated sources can't false-positive into this case).
- fix(types): `startStandalone(opt)` now declares the `implementation` option in its TypeScript signature. It was always accepted at runtime (`src/startStandalone.js` destructures `{ implementation, ...rest } = options`), but the public type only listed `qsProp` / `show` / `projectId` / `version`, so TypeScript users hit `TS2353 Object literal may only specify known properties` when wiring a custom implementation. Also adds public `Implementation` and `LocizeDetails` interfaces and types `getVueI18nImplementation` end-to-end (including `VueI18nImplementationOptions` for the second argument). `index.d.mts` was previously a one-line `export * from './index.js'` that gave ESM consumers no type information; it now mirrors `index.d.ts` directly so both CJS and ESM resolution paths see the same shape.
### 4.0.24
- fix InContext editor popup flashing briefly and then disappearing when the host application hydrates the full document via `hydrateRoot(document, ...)` (e.g. React Router v7 framework mode, and any other SSR framework that takes ownership of `` during hydration). When the server-rendered HTML and the client-rendered output diverged in any way — and the locize plugin itself can cause such a divergence on the client via i18next-subliminal, whose post-processor wraps translation values with invisible Unicode markers that are absent in the SSR pass — React's `clearContainerSparingly` (called from `commitBeforeMutationEffects` during hydration-mismatch recovery) removed any DOM children it didn't own, the popup included, producing the "popup visible for <1s then gone" symptom users reported on the React Router v7 + remix-i18next 7.x setup. `src/process.js` now (a) appends the popup to `document.documentElement` rather than into `` (so a mismatch that recovers only the `` container leaves the popup untouched), and (b) installs a short-lived MutationObserver that re-attaches the **same** popup element if it's removed in the first 10 seconds after init, capped at 5 reattachments. Re-using the same element (not a freshly built one) preserves all listeners that `initDragElement` / `initResizeElement` and the iframe URL wiring set up, so drag, resize, and the postMessage channel to the locize editor continue to work after a recovery. The watcher disconnects after the 10-second window so an intentional teardown later in the session is unaffected.
- fix `backendName` sent in `requestInitialize` payload not matching the locize editor's expected value. `src/implementations/i18nextImplementation.js` hardcoded `'I18nextLocizeBackend'` (lowercase "n") when it detected a Locize CDN `loadPath`, but the locize editor's `handleRequestInitialize` does a strict equality check against `'I18NextLocizeBackend'` (capital "N", matching the actual class name exported by `i18next-locize-backend`). The mismatch meant `currentConfig.isLocizeBackend` was always `false` in the editor even when the host application was clearly using `i18next-locize-backend`, which in turn caused the editor's Navigation dropdown (sync page entry, etc.) to be shown unconditionally. The hardcoded value now matches the upstream class name exactly.
- fix postMessage delivery to the InContext editor iframe being silently lost after a popup re-attachment. When the resurrection observer added in this release re-inserts the popup `` into the DOM after React's hydration recovery, browsers re-navigate the contained iframe to its `src` (per the HTML spec — removing an iframe and re-inserting it discards the original document and starts a new navigation). The host's cached `api.source` (= the iframe's `contentWindow`) then refers to the **first**, now-discarded `Window`, and every subsequent `postMessage` from `src/api/postMessage.js` — including the retried `requestInitialize` and the queued `sendCurrentTargetLanguage` / `sendCurrentParsedContent` — is swallowed by that defunct window. The new editor session in the iframe registers its listener but never sees a single message from the host, so the editor sits empty. Fixed by (a) re-resolving `document.getElementById('i18next-editor-iframe')?.contentWindow` on every `sendMessage` and clearing `api.initialized` when the source changes under us, (b) restoring the `repeat` retry budget on every fresh `requestInitialize` cycle (it was a module-scoped `let` that stayed negative after the first cycle exhausted it), and (c) wiping `api.source` / `api.initialized` / `api.initInterval` inside the iframe `load` callback in `src/process.js` so each load (initial or re-navigation) triggers a clean handshake.
### 4.0.23
- fix `isInIframe` incorrectly evaluating to `true` in Node 20+ SSR builds (Gatsby, Next.js, Astro, Nuxt, etc.). `src/utils.js`'s module-level iframe detection ran `self !== top` inside a try/catch that historically threw `ReferenceError` in Node, leaving the safe default. Since Node 20 added `self` as an alias for `globalThis` (with `top` still `undefined`), `self !== top` evaluates to `true` without throwing — making locize wrongly conclude it is running inside the Locize editor iframe during the SSR render pass. The check now runs only when `typeof window !== 'undefined'`; a thrown `top` access (cross-origin parent) is still treated as "in iframe", preserving the previous browser behaviour.
### 4.0.22
- fix InContext editor popup being draggable off-screen, making the title bar (and controls like "save") unreachable. `src/ui/popup.js` now clamps `top`/`left` during drag so the header row always stays within the viewport with a small grabbable margin on the sides. `src/api/handleRequestPopupChanges.js` applies the same clamp when restoring a previously stored position from `localStorage`, so users whose `locize_popup_pos` was saved off-screen in an earlier version auto-recover on reload (no more manual `localStorage` reset workaround).
### 4.0.21
Security release — all issues found via an internal audit. See published advisory [GHSA-w937-fg2h-xhq2](https://github.com/locize/locize/security/advisories/GHSA-w937-fg2h-xhq2).
- security: validate `event.origin` against the configured iframe origin (`getIframeUrl()`) at the top of the `window.addEventListener('message', …)` listener in `src/api/postMessage.js`. Prior to 4.0.21 the listener dispatched to registered handlers based only on attacker-controlled `event.data.sender` — any web page that could embed or be embedded by the locize-enabled host could invoke `editKey`, `commitKey`, `commitKeys`, `isLocizeEnabled`, `requestInitialize`, etc., against it. In combination with the `innerHTML`/`setAttribute` sinks in `handleEditKey`/`commitKeys`, this enabled cross-origin DOM XSS; via `isLocizeEnabled`, attackers could hijack `api.source`/`api.origin` and redirect all outgoing messages (CWE-346, CWE-79). The check is computed once at message time and uses the already-existing `getIframeUrl()` so custom environments (development/staging) continue to work ([GHSA-w937-fg2h-xhq2](https://github.com/locize/locize/security/advisories/GHSA-w937-fg2h-xhq2))
- security (defence-in-depth): harden the `editKey` handler in `src/api/handleEditKey.js`. On `attr:` writes, reject event-handler names (`on*`), `style`, and `javascript:` / `data:` / `vbscript:` / `file:` URLs on `href`/`src`/`action`/`formaction`/`xlink:href`. On `html` writes, parse the translation through a throwaway `DOMParser` document, strip `