WEB / WEB-11.03

iframe isolation and postMessage

Atlas uses a narrow message contract with a cross-origin read-only preview widget. A window reference, delivery and application acceptance are separate steps.

CORE · RED · BLUE · ARTIFACT · PRACTICE

Read every scenario without motion

Valid reply

Documents ready
Atlas parent and preview-one listeners are ready; the parent awaits a reply for tx-current. The cross-origin documents do not directly share DOM. No get-title message has yet been prepared or delivered.
Atlas · parent
Listeners ready; tx-current pending
Preview · iframe
Listeners ready; read-only title
Read-only request ready
The parent prepares a get-title request for the task queue using exact preview targetOrigin and the selected WindowProxy.
Atlas · parent
get-title queued; no delivery proof
Preview · iframe
Listeners ready; read-only title
Preview received event
The selected task target origin matched and the preview received a message event; application validation remains pending.
Atlas · parent
get-title queued; no delivery proof
Preview · iframe
Request event received; gates pending
Preview acceptance gate
The preview evaluated parent origin/source, read-only request schema and transaction conditions; no DOM sharing occurs.
Atlas · parent
get-title queued; no delivery proof
Preview · iframe
Request accepted; read-only title selected
Reply task ready
The preview prepared the selected title-result reply; even with a matching origin, the parent separately checks response transaction and instance.
Atlas · parent
get-title queued; no delivery proof
Preview · iframe
Reply queued; tx-current/preview-one
Parent received event
The reply message event arrived at the parent; origin/source/schema/transaction acceptance is a local gate after receipt.
Atlas · parent
Reply event received; acceptance pending
Preview · iframe
Reply queued; tx-current/preview-one
Parent acceptance gate
The parent checked all selected reply conditions together; the normal reply was accepted.
Atlas · parent
Reply accepted; no display update yet
Preview · iframe
Reply queued; tx-current/preview-one
Display binding
The selected text-only display was bound to the Atlas Notes alias; the model runs no actual DOM, message API or HTTP.
Atlas · parent
Declared text binding: Atlas Notları
Preview · iframe
Reply queued; tx-current/preview-one

Stale transaction

Documents ready
Atlas parent awaits tx-current and the preview-one listener is ready. This branch later selects a tx-old reply; delivery from the expected origin does not establish acceptance of an older transaction.
Atlas · parent
Listeners ready; tx-current pending
Preview · iframe
Listeners ready; read-only title
Read-only request ready
The parent prepares a get-title request for the task queue using exact preview targetOrigin and the selected WindowProxy.
Atlas · parent
get-title queued; no delivery proof
Preview · iframe
Listeners ready; read-only title
Preview received event
The selected task target origin matched and the preview received a message event; application validation remains pending.
Atlas · parent
get-title queued; no delivery proof
Preview · iframe
Request event received; gates pending
Preview acceptance gate
The preview evaluated parent origin/source, read-only request schema and transaction conditions; no DOM sharing occurs.
Atlas · parent
get-title queued; no delivery proof
Preview · iframe
Request accepted; read-only title selected
Reply task ready
The preview prepared the selected title-result reply; even with a matching origin, the parent separately checks response transaction and instance.
Atlas · parent
get-title queued; no delivery proof
Preview · iframe
Reply queued; tx-old
Parent received event
The reply message event arrived at the parent; origin/source/schema/transaction acceptance is a local gate after receipt.
Atlas · parent
Reply event received; acceptance pending
Preview · iframe
Reply queued; tx-old
Parent acceptance gate
The parent checked all selected reply conditions together; the reply was rejected for context mismatch.
Atlas · parent
Reply denied; display unchanged
Preview · iframe
Reply queued; tx-old
Display binding
The parent received the reply event, but tx-old did not match pending tx-current. No display binding occurred. Message receipt is not transaction acceptance; no actual DOM or HTTP executes here.
Atlas · parent
No display binding; rejected reply
Preview · iframe
Reply queued; tx-old

Other instance

Documents ready
Two owned previews share an origin; selected wiring reaches preview-two while pending context expects preview-one.
Atlas · parent
Expected preview-one; tx-current
Preview · iframe
Current preview-two; same origin
Read-only request ready
The parent prepares a get-title request for the task queue using exact preview targetOrigin and the selected WindowProxy.
Atlas · parent
get-title queued; no delivery proof
Preview · iframe
Current preview-two; same origin
Preview received event
The selected task target origin matched and the preview received a message event; application validation remains pending.
Atlas · parent
get-title queued; no delivery proof
Preview · iframe
Request event received; gates pending
Preview acceptance gate
The preview evaluated parent origin/source, read-only request schema and transaction conditions; no DOM sharing occurs.
Atlas · parent
get-title queued; no delivery proof
Preview · iframe
Request accepted; read-only title selected
Reply task ready
The preview prepared the selected title-result reply; even with a matching origin, the parent separately checks response transaction and instance.
Atlas · parent
get-title queued; no delivery proof
Preview · iframe
Reply queued; preview-two
Parent received event
The reply message event arrived at the parent; origin/source/schema/transaction acceptance is a local gate after receipt.
Atlas · parent
Reply event received; acceptance pending
Preview · iframe
Reply queued; preview-two
Parent acceptance gate
The parent checked all selected reply conditions together; the reply was rejected for context mismatch.
Atlas · parent
Reply denied; display unchanged
Preview · iframe
Reply queued; preview-two
Display binding
The reply has the expected origin and tx-current, but its source is preview-two rather than expected preview-one. The parent rejects acceptance and does not bind the display: the same origin does not mean the same Window instance.
Atlas · parent
No display binding; rejected reply
Preview · iframe
Reply queued; preview-two

Frame changed

New receiver context
The preview document now has origin preview-v2.example.org, while Atlas parent uses the old exact target preview.example.org. A browser-local task compares them later; the sender has not received delivery or rejection information.
Atlas · parent
Exact target preview.example.org
Preview · iframe
Current document preview-v2.example.org
Request queue
The parent queues the normal read-only request with the earlier exact target; call return is not a delivery acknowledgment.
Atlas · parent
Request queued; no acknowledgment
Preview · iframe
Current document preview-v2.example.org
Local target gate
The browser-local task gate compares the current receiver document origin with the exact target; mismatch creates no event.
Atlas · parent
Request queued; no acknowledgment
Preview · iframe
Target mismatch; zero message events
No reply
The selected observer event count is zero; the sender is not assumed to learn this gate result from the real postMessage API.
Atlas · parent
No reply observed; no display update
Preview · iframe
Target mismatch; zero message events

ACTORS · STATE · DATA FLOW

Seeing an iframe does not mean reading its document

Atlas embeds a document from preview.example.org in an iframe. In an ordinary cross-origin case, the parent can obtain a WindowProxy through contentWindow, but that reference grants no general access to the preview DOM. Limited surfaces such as postMessage are available while direct document reads depend on the origin gate. A same-origin iframe shares broader script access; the iframe element alone is not strong isolation for every document. Browser process selection is not equivalent to this visible DOM box either.

Sandbox adds separate capability boundaries. With the sandboxed origin flag active, a document has an opaque origin even if its HTTP URL matches; the script flag independently controls script execution. allow-same-origin does not make a different origin equal to the parent; it removes the origin sandbox restriction and retains the document’s ordinary origin context. This lesson selects normal tuple-origin preview messaging and does not recommend wildcards for confidential messaging to opaque sandboxes. Actual sandbox and framing enforcement remains a separate browser test.

A message contract is not a network transport

The parent sends only a v1 get-title request with transactionAlias=tx-current and bookAlias=atlas-notlari. postMessage carries data through structured serialization and a queued message event, not an HTTP packet or direct DOM sharing. The selected exact targetOrigin=https://preview.example.org must match the receiver document’s origin when the task runs. A WindowProxy can represent another document after navigation. Returning from the sending call proves neither delivery nor receiver acceptance.

The preview checks event.origin against the expected parent origin, event.source against the selected parent WindowProxy, data against the exact read-only schema and transaction against pending context. The reply uses the contract’s title-result shape. The parent checks preview origin and selected preview WindowProxy before shape and current transaction. event.origin records the sender origin at call time, not the receiver document origin or a future navigation of the source window. A reply target is chosen from context already validated.

Structured cloning does not validate business meaning. The fixture transfers no MessagePort or other transferable; ports=[] is explicit. If a MessageChannel is later established, port possession and lifecycle need a separate capability contract; window-message origin/source checks are not blindly copied onto every port event. Multiple requests and asynchronous work can change reply order; transaction binding avoids assuming the first reply belongs to the current request. This model runs no full task scheduler or port transfer.

Read every scenario without motion

Stale reply

Identify pending work
The parent awaits title-result for tx-current from preview-one. Even a correct event origin does not identify which pending task or window produced the result.
Preview reply record
tx-current / preview-one
Parent acceptance rule
Not yet evaluated
Title binding result
Not yet evaluated
Stale transaction
The stale-reply record carries tx-old and Earlier Atlas title. Origin and source remain correct, but the transaction differs; title-result alone is insufficient.
Preview reply record
tx-current / preview-one
Parent acceptance rule
tx-old ≠ tx-current / reject
Title binding result
Not yet evaluated
Retain the title
The parent does not accept the stale reply. An event is not an application acknowledgment, and the earlier title is not bound to the current request.
Preview reply record
tx-current / preview-one
Parent acceptance rule
tx-old ≠ tx-current / reject
Title binding result
Current title unchanged
Second window
The instance-mismatch reply comes from the same preview origin but sourceWindow is preview-two. The pending work belongs to preview-one; equal origins do not merge WindowProxy identities.
Preview reply record
Same origin / preview-two
Parent acceptance rule
tx-old ≠ tx-current / reject
Title binding result
Current title unchanged
Validate together
Origin, source, type, v, transactionAlias, bookAlias and title type are checked together. This read-only contract selects text; it grants neither API user authority nor DOM rendering success.
Preview reply record
Same origin / preview-two
Parent acceptance rule
Origin + source + shape + transaction
Title binding result
Current title unchanged
Stop wrong binding
Wrong instance and stale transaction are independent rejection reasons. Both retain the current title; an accepted normal reply may update only its associated read-only result.
Preview reply record
Same origin / preview-two
Parent acceptance rule
Origin + source + shape + transaction
Title binding result
Rejected replies / no title update

Delivery boundary

Record exact target
The request targetOrigin is https://preview.example.org. It narrows the intended destination; return from postMessage does not prove receiver acceptance.
Preview reply record
targetOrigin = preview origin
Parent acceptance rule
Not yet evaluated
Title binding result
Not yet evaluated
Navigation difference
In frame-navigation the destination becomes https://preview-v2.example.org. The delivery gate checks the current Document origin at task time and does not deliver a mismatching event.
Preview reply record
targetOrigin = preview origin
Parent acceptance rule
Destination changed / delivered false
Title binding result
Not yet evaluated
Do not count an absent event
This branch cannot produce parent acceptance or preview handler success. The drawn decision does not mean the sender receives an automatic delivery acknowledgment from the API.
Preview reply record
targetOrigin = preview origin
Parent acceptance rule
Destination changed / delivered false
Title binding result
No request event / acceptance absent
Reference is not permission
The cross-origin iframe has a WindowProxy reference but directDomReadable is false. A reference usable for messaging does not permit reading the preview Document DOM.
Preview reply record
WindowProxy available / DOM unreadable
Parent acceptance rule
Destination changed / delivered false
Title binding result
No request event / acceptance absent
Retain lifecycle binding
Pending work remains bound to an instance and transaction. Listeners are assumed ready; actual browser navigation, timeout or listener races are not measured here.
Preview reply record
WindowProxy available / DOM unreadable
Parent acceptance rule
Instance-bound pending work
Title binding result
No request event / acceptance absent
Two-stage boundary
Exact destination and application acceptance are separate controls. One constrains event delivery; the other checks whether the delivered read-only result belongs to the correct task.
Preview reply record
WindowProxy available / DOM unreadable
Parent acceptance rule
Instance-bound pending work
Title binding result
Delivery ≠ application acceptance

ASSUMPTION · BOUNDARY · CONTROL

Which reply does origin alone select?

Atlas can open two preview instances at the same origin. In instance-mismatch, the reply origin is correct but source alias preview-two is not the preview-one expected by the pending request. The parent rejects it. This is an ordinary widget-wiring error, not a payload or intervention against another target. Expected origin alone identifies neither the window nor the transaction producing a result. Incorrect acceptance would display the wrong title in this read-only example; stronger message actions require their own authorization boundary.

In stale-reply, the ordinary preview receives the current request but a selected stale result returns with tx-old. The parent leaves the title unchanged because the result does not match its current transaction. Delivery precedes application validation. Receiving a message event does not imply schema or transaction acceptance. In frame-navigation, the exact-target gate does not match and no request event is created; the sender is not assumed to receive an automatic delivery acknowledgment.

Opaque identity and message shape

Serialized null does not make all opaque senders one trusted widget here either. Schema fields type, v, transaction and book restrict the permitted read-only job; treating data as HTML or executable text would be outside that contract. This lesson selects a no-eval, text-only result profile without running a real renderer. Control effects stay between event acceptance and selected display binding; an origin check is not presented as API user/tenant authorization.

Read every scenario without motion

Reply controls

Normal reply record
This artifact separates Window-message delivery predicates from receiver acceptance. deliveryCases predicts whether a browser-local task creates an event; replyCases predicts the parent’s origin/source/type/transaction comparisons. These are not real postMessage or HTTP records: event receipt precedes acceptance and display binding. frame-navigation creates no preview event; stale-reply and instance-mismatch reach a parent event and are then rejected. The normal reply carries the preview origin, preview-one source and tx-current. Its type is title-result, v is 1, bookAlias is atlas-notlari, and title is the string Atlas Notları.
Event ledger
Normal / tx-current / title string
Correlation review
Not yet evaluated
Acceptance evidence
Not yet evaluated
Positive control
All acceptance conditions pass in the normal row. This positive control lets the model compare later rejections without treating every result as a broken test setup.
Event ledger
Normal / tx-current / title string
Correlation review
Normal accepted true
Acceptance evidence
Not yet evaluated
Separate negative controls
Stale-reply fails transaction, instance-mismatch fails source, shape-mismatch fails title type 17, and origin-mismatch fails origin. Each reason is retained separately.
Event ledger
Normal / tx-current / title string
Correlation review
Normal accepted true
Acceptance evidence
Four independent rejection reasons
Separate delivery record
Normal delivery is true and frame-navigation delivery is false. Rejecting a reply differs from having no request event; an empty parent reply list alone cannot distinguish them.
Event ledger
Delivery normal true / navigation false
Correlation review
Normal accepted true
Acceptance evidence
Four independent rejection reasons
Narrow correlation
Expected source alias and pending transaction are retained together. The event origin string does not replace window identity, and accepting text is not server action authority.
Event ledger
Delivery normal true / navigation false
Correlation review
Origin/source/transaction scopes retained
Acceptance evidence
Four independent rejection reasons
Regression boundary
The acceptance matrix compares a normal reply with separate negatives. Actual iframe, cloning, port transfer and DOM rendering are not verified by this record; it explains the message contract decision.
Event ledger
Delivery normal true / navigation false
Correlation review
Origin/source/transaction scopes retained
Acceptance evidence
Finite contract verified / browser unmeasured

Event gap

Empty reply view
This artifact separates Window-message delivery predicates from receiver acceptance. deliveryCases predicts whether a browser-local task creates an event; replyCases predicts the parent’s origin/source/type/transaction comparisons. These are not real postMessage or HTTP records: event receipt precedes acceptance and display binding. frame-navigation creates no preview event; stale-reply and instance-mismatch reach a parent event and are then rejected. The reviewer has no reply event record. Absence alone cannot select a navigation delivery block, listener readiness problem or another lifecycle state.
Event ledger
Reply observation missing
Correlation review
Not yet evaluated
Acceptance evidence
Not yet evaluated
Do not copy expectations
The normal request and response show the expected tx-current contract. Copying normal origin/source/title fields into an incomplete trace would invent acceptance.
Event ledger
Reply observation missing
Correlation review
Expected contract ≠ missing event
Acceptance evidence
Not yet evaluated
Retain the unknown result
Without an event, title-result acceptance or rejection is unknown. An unchanged display alone does not prove the delivery decision; different stages can yield the same visible result.
Event ledger
Reply observation missing
Correlation review
Expected contract ≠ missing event
Acceptance evidence
Delivery/acceptance UNKNOWN
Select necessary context
The destination context at task time, window instance and pending transaction are needed. In actual product observation, listener readiness and lifecycle timing must also be associated with that work.
Event ledger
Needed: destination/instance/transaction
Correlation review
Expected contract ≠ missing event
Acceptance evidence
Delivery/acceptance UNKNOWN
Read the model boundary
The listenersReady true starting assumption is not a measured delay. An HTTP record cannot replace a postMessage event, which belongs to a different browser-local mechanism.
Event ledger
Needed: destination/instance/transaction
Correlation review
Ready assumption / no HTTP evidence
Acceptance evidence
Delivery/acceptance UNKNOWN
Question for new evidence
A new observation must answer delivery, event receipt and application acceptance separately. This incomplete record remains UNKNOWN; the normal fixture title is not inserted into the gap.
Event ledger
Needed: destination/instance/transaction
Correlation review
Ready assumption / no HTTP evidence
Acceptance evidence
Collect scoped event/acceptance evidence

IMPLEMENTATION · SECURITY CONTROL · VERIFICATION

Narrow, instance-bound message acceptance

This artifact separates Window-message delivery predicates from receiver acceptance. deliveryCases predicts whether a browser-local task creates an event; replyCases predicts the parent’s origin/source/type/transaction comparisons. These are not real postMessage or HTTP records: event receipt precedes acceptance and display binding. frame-navigation creates no preview event; stale-reply and instance-mismatch reach a parent event and are then rejected. Atlas obtains expected origin from configuration and expected WindowProxy from its selected iframe instance. The sender uses an exact targetOrigin; the receiver validates origin, source and schema together. Source identity is not converted into an origin string: two windows at the same origin remain distinct. Type is restricted to get-title/title-result, version to 1, transaction to pending tx-current and book to the selected read-only alias. An unknown type or extra field does not silently become a stronger action; the selected schema rejects it.

Regression uses the normal result as a positive control and separates stale transaction, wrong instance, wrong shape and changed destination origin as negative controls. The scene leaves a received request pending at the preview, prepares a reply only after local acceptance, and separates parent response receipt from validation. A title enters the display binding only after all selected reply gates pass. The dropped-destination branch draws no transfer; displaying the browser-local task gate does not claim the sender learned that decision from the real API.

Readiness and lifecycle boundaries

Recipient readiness and lifecycle are part of the contract. Prepare the listener, and cancel or restart instance-specific pending work when iframe navigation changes its document context. The model assumes documents/listeners-ready initially; this is not a measured browser timeout, WindowProxy-navigation or port-transfer outcome. Correlate real lifecycle events with the same instance.

NOW APPLY IT TO THE CASE

Is receiving the message enough to update the title?

Atlas expects the Atlas Notları title from preview-one for tx-current. A tx-old reply or a result from preview-two at the same origin does not complete that request. Navigation to another origin can also prevent the request event through exact targetOrigin.

Which relationship does the case’s browser policy control? Explain exposure, destination or framing decisions separately from server object permission.

Open the related case file ↗

READ THE EXAMPLE TOGETHER

Read-only preview message contract

Select a field and examine what it supports and where the evidence ends.

Read the raw artifact and field explanations

{
  "profile": {
    "parentOrigin": "https://atlas.example.org",
    "previewOrigin": "https://preview.example.org",
    "expectedParentWindow": "parent-one",
    "expectedPreviewWindow": "preview-one",
    "listenersReady": true,
    "currentTransaction": "tx-current",
    "exactTarget": true,
    "actualBrowser": false,
    "actualDOM": false,
    "actualPostMessage": false,
    "portTransfer": false,
    "scriptEvaluation": false
  },
  "iframe": {
    "normalCrossOrigin": true,
    "directDomReadable": false,
    "windowProxyReferenceAvailable": true,
    "sandboxOriginProfile": "not selected for messaging; opaque distinction taught separately",
    "sameOriginWouldNotBeIsolatedByElementAlone": true
  },
  "request": {
    "type": "get-title",
    "v": 1,
    "transactionAlias": "tx-current",
    "bookAlias": "atlas-notlari"
  },
  "response": {
    "type": "title-result",
    "v": 1,
    "transactionAlias": "tx-current",
    "bookAlias": "atlas-notlari",
    "title": "Atlas Notları"
  },
  "deliveryCases": [
    {
      "case": "normal",
      "targetOrigin": "https://preview.example.org",
      "currentDestinationOrigin": "https://preview.example.org",
      "expectedDelivered": true
    },
    {
      "case": "frame-navigation",
      "targetOrigin": "https://preview.example.org",
      "currentDestinationOrigin": "https://preview-v2.example.org",
      "expectedDelivered": false
    }
  ],
  "replyCases": [
    {
      "case": "normal",
      "origin": "https://preview.example.org",
      "sourceWindow": "preview-one",
      "data": {
        "type": "title-result",
        "v": 1,
        "transactionAlias": "tx-current",
        "bookAlias": "atlas-notlari",
        "title": "Atlas Notları"
      },
      "ports": [],
      "expected": true
    },
    {
      "case": "stale-reply",
      "origin": "https://preview.example.org",
      "sourceWindow": "preview-one",
      "data": {
        "type": "title-result",
        "v": 1,
        "transactionAlias": "tx-old",
        "bookAlias": "atlas-notlari",
        "title": "Earlier Atlas title"
      },
      "ports": [],
      "expected": false
    },
    {
      "case": "instance-mismatch",
      "origin": "https://preview.example.org",
      "sourceWindow": "preview-two",
      "data": {
        "type": "title-result",
        "v": 1,
        "transactionAlias": "tx-current",
        "bookAlias": "atlas-notlari",
        "title": "Atlas Notları"
      },
      "ports": [],
      "expected": false
    },
    {
      "case": "shape-mismatch",
      "origin": "https://preview.example.org",
      "sourceWindow": "preview-one",
      "data": {
        "type": "title-result",
        "v": 1,
        "transactionAlias": "tx-current",
        "bookAlias": "atlas-notlari",
        "title": 17
      },
      "ports": [],
      "expected": false
    },
    {
      "case": "origin-mismatch",
      "origin": "https://preview-v2.example.org",
      "sourceWindow": "preview-one",
      "data": {
        "type": "title-result",
        "v": 1,
        "transactionAlias": "tx-current",
        "bookAlias": "atlas-notlari",
        "title": "Atlas Notları"
      },
      "ports": [],
      "expected": false
    }
  ],
  "deliverySemantics": {
    "callReturnIsAcknowledgement": false,
    "originCapturedAtSenderCall": true,
    "sourceIsWindowProxy": true,
    "receiverCurrentDocumentOriginCheckedAtTask": true,
    "applicationValidationAfterEvent": true,
    "httpTraffic": false
  },
  "omitted": [
    "actual iframe creation/navigation/sandbox",
    "full structured clone",
    "browser event loop and listener races",
    "MessageChannel/MessagePort transfer",
    "timeouts and multiple asynchronous replies",
    "API authorization and DOM rendering"
  ]
}

iframe: A WindowProxy reference is not DOM permission; sandbox adds separate limits.
request: Exact read-only message schema and pending transaction.
deliveryCases: Delivery gate depends on receiver origin at task time.
replyCases: Receiver origin/source/schema/transaction conjunction.
deliverySemantics: API call return, event receipt and acceptance are separate.

Window/source identities are aliases and events are inert JSON. No browser, actual postMessage, HTTP, DOM, clone or port transfer runs.

Two reality checks

Having contentWindow makes the iframe DOM readable.

A cross-origin WindowProxy exposes a limited surface; direct DOM access has a separate origin gate.

A matching event.origin is enough to accept a reply.

The selected window source, read-only schema and current transaction must also match.

YOUR TURN

Work through this story.

Predict the outcome, find the evidence boundary, and explain it in your own words.

Reply origin/source match, but the transaction is tx-old. Is it accepted as the current title result?

No; a stale reply is not bound to the current transaction.
Yes; the correct origin makes all past replies current.

Read the explained answer

No; a stale reply is not bound to the current transaction. — CurrentTransaction is tx-current; an old reply from the same Window/origin is not a current result.

The frame navigated to preview-v2 while targetOrigin is preview. Is sender-call return a delivery ACK?

Selected lesson artifact fields; teaching example

deliveryCases[1]: {"case":"frame-navigation","targetOrigin":"https://preview.example.org","currentDestinationOrigin":"https://preview-v2.example.org","expectedDelivered":false}
deliverySemantics.callReturnIsAcknowledgement: false

Yes; an unchanged WindowProxy makes origin changes irrelevant.
No; selected expectedDelivered=false and call return is not an ACK.

Read the explained answer

No; selected expectedDelivered=false and call return is not an ACK. — An exact-target mismatch closes delivery; postMessage return does not replace application acknowledgement.

Why is a reply with the correct origin but sourceWindow preview-two rejected? Also explain the shape/title-type gate.

Read the explained answer

The expected preview-one WindowProxy instance is required; another instance with the same origin is not the peer of this conversation. Data type/version/book/transaction and the title-string shape are additionally validated. Even an accepted message body is not evidence of API-resource authorization or DOM rendering.

□ I separated origin from the exact source instance.

□ I preserved shape/transaction gates.

Open the application console · request / response / browser

Also open request, URL, cookie and DOM examples

Sources and scope

WHATWG HTML — Cross-document messaging§9.3.2.1 Authors: expected origin, expected format, targetOrigin · §9.3.3 Posting messages: structured serialization, queued task, target origin check, event source/origin/data/ports · §9.4 Channel messaging: separate messaging surface
MDN — Window.postMessage()Parameters: targetOrigin, transfer; Return value · The dispatched event: origin, source, data · Security concerns; Notes
WHATWG HTML — Origins and sandboxing§7.1.1 Origins: tuple/opaque, serialization, same-origin equality · §7.1.1.1 Sites; §7.1.1.2 Relaxing the same-origin restriction · §7.1.5 Sandboxing: sandboxed origin and scripts flags
MDN — Same-origin policyDefinition of an origin; Inherited origins; File origins · Cross-origin network access: writes, embeds, reads · Cross-origin script API access: Window and Location · Cross-origin data storage access

YOUR NOTES / THIS BROWSER

iframe isolation and postMessage

1. Core · Mechanism

Valid reply

Stale transaction

Other instance

Frame changed

Seeing an iframe does not mean reading its document

A message contract is not a network transport

2. Red · Trust & Impact

Stale reply

Delivery boundary

Which reply does origin alone select?

Opaque identity and message shape

3. Blue · Secure development & defense

Reply controls

Event gap

Narrow, instance-bound message acceptance

Readiness and lifecycle boundaries

Is receiving the message enough to update the title?

Two reality checks

Reply origin/source match, but the transaction is tx-old. Is it accepted as the current title result?

The frame navigated to preview-v2 while targetOrigin is preview. Is sender-call return a delivery ACK?

Why is a reply with the correct origin but sourceWindow preview-two rejected? Also explain the shape/title-type gate.

Sources and scope