## EVIDENCE STATE Mode: EVIDENCE. Current supplied runtime: WordPress 7.0.2. Block: `apiVersion: 2`. Observed contexts: - desktop Post Editor works; - Site Editor preview shows an empty map; - failing iframe context logs that `.map-canvas` is not found. Not executed: Gutenberg 23.6+, WordPress 7.1, or any post-fix probe. Official WordPress docs are decisive: 7.0 retains a conditional non-iframe fallback, while Gutenberg 23.6 and WordPress 7.1 use an iframed Post Editor regardless of block API version. Editor scripts run in the admin page while content has another `document`/`window`. ## CONTRACT LEDGER ### I1 — Map renders inside the block canvas Type: BLOCK CONTENT + THIRD-PARTY WIDGET. Required: the library must initialize against the actual `.map-canvas` element in the content document. Current evidence: works in one desktop context; fails in an iframe context. Verdict: **PARENT-DOCUMENT-COUPLED** ### I2 — Map responds to editor viewport resize Type: DOM EVENT. Required: resize handling must observe the window that owns the map/content behavior, or another evidenced correct resize surface. Current: global `window.addEventListener`. Verdict: **PARENT-DOCUMENT-COUPLED / INSUFFICIENT-EVIDENCE** The parent admin window is not proven to be the correct event owner. ### I3 — Map styling is present in editor content Type: STYLE. Current: CSS only through `admin_enqueue_scripts`. Observed: empty map may be caused primarily by failed initialization, but CSS delivery into the iframe is not evidenced. Verdict: **STYLE-ISOLATION-DRIFT** ## DOCUMENT BOUNDARY ### D1 — `document.querySelector('.map-canvas')` Intended target: block content node. Actual scope: the global document available to the editor script — the admin parent document. Status: **WRONG DOCUMENT** This explains the null target in iframe content. ### D2 — global `window` Intended target: not explicitly stated. Actual scope: parent window. Status: **WRONG WINDOW** until the resize requirement proves otherwise. ### D3 — map element The correct anchor is the rendered block node. Migration should derive context from that node rather than search globally. ## ASSET & STYLE SURFACES Current CSS hook: `admin_enqueue_scripts`. Classification: likely **PARENT-ONLY** for the supplied content requirement. WordPress documentation distinguishes Editor UI assets from Editor content assets. For a block, prefer block metadata for block-specific styles, or an editor-content loading path documented for the supported version. Minimal direction: - shared map/block styles needed in editor + front end → `style`; - editor-only block-content styling → `editorStyle`; - do not move unrelated admin UI CSS into the iframe. ## LIBRARY BOUNDARY The map library is initialized with an element, which is promising. However, no supplied library source proves whether its internal pointer/resize/event behavior later reaches global `document` or `window`. Status: **UNKNOWN / TARGETABLE candidate** Do not call it iframe-safe from initialization alone. ## MIGRATION PATCH ### 1 — Ref-bind the content element Use a block ref instead of global lookup. Conceptual shape: block root/ref → locate or own the map canvas relative to that block → obtain `ownerDocument` → obtain `ownerDocument.defaultView` → initialize the map with the actual element. For React block behavior that attaches/detaches event listeners, current WordPress migration guidance recommends `useRefEffect` because it can re-run when the referenced element changes. ### 2 — Bind resize to evidenced relative context If the library truly needs its owning window: `const { defaultView } = element.ownerDocument` Bind there and return cleanup from the ref effect. Do not keep the parent-window listener just because fallback worked. ### 3 — Fix block-content CSS delivery Move block styling to `block.json` `style` / `editorStyle` as appropriate, or another documented editor-content path. ### 4 — Inspect the map library Search its relevant event code for global: `document` `window` pointer/mouse/touch listeners resize handlers. If it accepts a target/context, use it. If the library hardcodes globals, classify PATCHABLE / UPSTREAM REQUIRED / REPLACE based on actual source. Do not guess. ### 5 — Upgrade `apiVersion` only after behavior is iframe-safe Changing `2` → `3` is a declaration/config migration, not the fix for D1/D2. ## READINESS VERDICT I1: **PARENT-DOCUMENT-COUPLED** I2: **PARENT-DOCUMENT-COUPLED / INSUFFICIENT-EVIDENCE** I3: **STYLE-ISOLATION-DRIFT** Overall: **DO NOT SHIP** as WordPress 7.1 iframe-ready. The Site Editor failure already proves a document-boundary defect. ## IFRAME PROBES All are **PROPOSED**. ### P1 — forced iframe load Use a supported test environment where the Post Editor is always iframed. Pass: map initializes without null-target errors. ### P2 — interaction Pan/zoom/select the map. Pass: pointer and keyboard interactions behave inside the block. ### P3 — resize Resize editor canvas/device preview. Pass: map recalculates correctly without duplicate listeners. ### P4 — remount Remove/undo/reinsert the block or trigger an editor remount. Pass: old listeners/library instances are cleaned; one active instance remains. ### P5 — style Inspect the iframe content. Pass: required block styles are present without depending on parent-admin CSS. ### P6 — front end Render the same block publicly. Pass: the migration did not break front-end map behavior. ## SAFE CLAIM “The block currently works only in at least one non-equivalent editor context. A confirmed iframe context already exposes global-document coupling; WordPress 7.1 readiness is not established.” ## RECOVERY DELTA After the ref/context and asset changes, keep the observed Site Editor failure as baseline evidence. Reopen I1–I3 plus the library matrix and run P1–P6 only.