Realms, globals & WindowProxy

One realm per global

A page does not run JavaScript in one universal bucket. A realm is one JavaScript global environment: it has a global object, global names, and its own built-in objects such as Array, Object, and Function.

1globalThis.lessonName = "realms";2console.log(globalThis.lessonName);

Line 1 stores a property on this realm's global object. Line 2 reads the same property and prints realms. Another iframe has a different global object, so it does not gain this property by accident.

1globalThis.cartName = "parent cart";2const frameGlobal = { cartName: "frame cart" };3 4console.log(globalThis.cartName);5console.log(frameGlobal.cartName);6 7// A real iframe has a separate global object, not this plain teaching object.

Line 1 gives the parent global one cart name. Line 2 is a tiny teaching stand-in for another global, with its own name. Lines 4 and 5 print parent cart and frame cart. In a browser, an iframe supplies that separate global environment for real.

This separation prevents accidental sharing. A variable placed on one page's global object does not become a variable in every frame. Code can still communicate, but it must deliberately use a same-origin reference or a message boundary.

This matters when a page embeds a checkout, an editor, a preview, or an old application inside an iframe. Each frame can run familiar JavaScript, yet each frame owns distinct constructors and global state. The previous Bindings: how DOM objects exist in JavaScript lesson explains how browser objects appear in one realm.

Each iframe has its own intrinsics

Intrinsics are the built-in objects that make JavaScript work, including constructors and their prototypes. The parent page's Array and an iframe's Array have the same job, but they are different objects.

1const frame = document.createElement("iframe");2document.body.append(frame);3 4const FrameArray = frame.contentWindow.Array;5const list = new FrameArray("tea");6 7console.log(list instanceof Array);8console.log(Array.isArray(list));

Line 1 creates a blank iframe. Line 2 places it in the document so it receives a window. Line 4 reads that window's Array, and line 5 creates a list with it. Line 7 prints false; line 8 prints true.

The first result surprises people because instanceof follows a prototype chain and compares it to this realm's Array.prototype. The second result asks a different question: is this value an array? That works across realm boundaries.

Try this iframe example in the console of a normal page you control. The lesson editor sandbox has an opaque origin, so reading even a blank iframe's contentWindow.Array throws a SecurityError there.

Window and WindowProxy

Window is the document's actual global object. WindowProxy is the stable object exposed when one browsing context refers to another through contentWindow, parent, or frames.

1const frame = document.querySelector("iframe");2const room = frame.contentWindow;3 4console.log(room === frame.contentWindow);5frame.src = "/next-page";6console.log(room === frame.contentWindow);

Line 2 saves the frame reference. Line 4 begins a navigation. The source is shown for reading, not running, because this lesson sandbox has no /next-page. The important idea is that the reference stays useful while the active document and its Window can change.

Think of WindowProxy as a school reception desk. You always speak to the reception, and it forwards you to the current teacher in that room. When the room changes teacher after navigation, the desk reference still works.

Entry, incumbent, current, relevant

The HTML specification has four labels for realm-sensitive algorithms. They solve platform edge cases, not ordinary application decisions. Most code only ever needs current and relevant.

1const frame = document.querySelector("iframe");2const printInFrame = frame.contentWindow.print;3printInFrame.call(frame.contentWindow);

Line 1 gets a frame. Line 2 reads a method from that frame. Line 3 calls the method with the frame as its receiver. This is only a small picture; specifications use the labels below when their algorithms must decide whose settings or global object matter.

• Entry realm: the script that initiated the currently running script action.
• Incumbent realm: the most recently entered author code, or code that scheduled a callback.
• Current realm: the realm of the function currently running.
• Relevant realm: the realm belonging to a particular platform object, usually its creation realm.

For example, a method invoked on a frame's DOM object usually needs that object's relevant realm. The standards warn new specifications away from entry and incumbent when possible because their callback history is difficult to reason about.

1const callback = {2  entry: "the script that began this work",3  incumbent: "the author code that scheduled it",4  current: "the function running now",5  relevant: "the realm of the platform object",6};7 8console.log(callback.current);9console.log(callback.relevant);10 11// These strings are a vocabulary aid, not browser introspection.

Lines 1 through 6 store one plain explanation for each label. Lines 8 and 9 print the function running now and the realm of the platform object. This is not a browser API that reveals hidden realm state; it is a small way to keep the four terms separate while reading a specification.

When application code calls a method, start with the receiver. A frame-owned DOM node normally brings its relevant realm with it. The current realm is simply where the function body is running at that moment.

Cross-realm objects and instanceof

Cross-realm object means a value made in one realm and inspected or used in another. Arrays are the friendliest demonstration because both realms expose an Array name, but those names refer to different constructor objects.

1const parentArray = ["tea"];2const frameArray = new FrameArray("tea");3 4console.log(parentArray instanceof Array);5console.log(frameArray instanceof Array);6console.log(Array.isArray(frameArray));

Line 1 creates an ordinary parent array. Line 2 creates a frame array. Line 4 is true because the parent made that value. Line 5 is false, while line 6 is true because Array.isArray is the right cross-realm predicate.

Do not turn this into a rule that instanceof is broken. It is doing an identity-based prototype test. It is useful when the constructor identity is part of the contract. When you only need to recognize arrays from unknown realms, prefer Array.isArray.

1const frameArray = ["tea"];Run2Object.setPrototypeOf(frameArray, null);3 4const parentThinksItIsAnArray = frameArray instanceof Array;5const parentRecognizesAnArray = Array.isArray(frameArray);6 7console.log(parentThinksItIsAnArray);8console.log(parentRecognizesAnArray);

The step-through uses a runnable stand-in: it removes an ordinary array's parent prototype, so instanceof is false while Array.isArray remains true. A real iframe has its own prototype; use the earlier example in a normal page's console to observe that browser boundary directly.

Compare two realms

The playground uses two named realms and one array. Pick who creates the array, then pick whose instanceof Array check runs. Reset returns to the useful cross-realm case: iframe creates, parent checks.

1const frameArray = ["tea"];2Object.setPrototypeOf(frameArray, null);3 4const parentThinksItIsAnArray = frameArray instanceof Array;5const parentRecognizesAnArray = Array.isArray(frameArray);6 7console.log(parentThinksItIsAnArray);8console.log(parentRecognizesAnArray);

Every combination still reports true for Array.isArray. That result is the point: the value's array nature and the identity of a realm's Array constructor are different facts.

Same-origin frames

The same-origin policy controls direct access between documents. Same-origin frames can read each other's document and JavaScript objects. Cross-origin frames cannot read ordinary properties such as document; browsers throw a SecurityError.

1const frame = document.createElement("iframe");2frame.onload = () => {3  console.log(frame.contentWindow.document.body.textContent);4};5frame.srcdoc = "<p>Same-origin frame</p>";6document.body.append(frame);

Line 1 creates an iframe. Lines 2 through 4 install a load handler before line 5 supplies same-origin HTML. The handler reads the document body and prints Same-origin frame. This works because the generated document belongs to this page's origin. Try it in the console of a normal page you control; the lesson editor sandbox has an opaque origin and blocks reads from contentWindow.

Cross-origin windows still allow a narrow set of safe operations. A page can call postMessage and can assign a cross-origin frame's location, but it cannot inspect the other document. See Windows and frames for the browsing-context details.

1const frame = document.querySelector("iframe");2 3window.addEventListener("message", (event) => {4  console.log(event.data);5});6 7frame.contentWindow.postMessage({ type: "cart", count: 3 }, "*");

Line 3 listens for a message. Line 7 sends plain data to the frame. In production, replace * with the receiver's exact origin and validate event.origin plus the message shape before acting.

1const event = {2  origin: "https://checkout.example",3  data: { type: "order-ready", id: "tea-3" },4};5 6const isExpected = event.origin === "https://checkout.example" && event.data.type === "order-ready";7console.log(isExpected);8 9// A receiver checks origin and message shape before using the data.

Lines 1 through 4 describe one received event. Line 6 checks both its origin and its message type. Line 7 prints true only for the expected checkout event. Real code should reject unfamiliar origins and data before it changes a cart or account.

Serializable and transferable values

Frame boundaries often need data rather than direct object access. Structured clone creates a supported data value in another context. It copies serializable values. A transfer moves ownership of a transferable value instead of copying it.

1const cart = { item: "tea", count: 3 };2const copy = structuredClone(cart);3 4copy.count = 4;5console.log(cart.count);6console.log(copy.count);

Line 1 creates the original cart. Line 2 copies it. Line 4 changes only the copy. The logs print 3 then 4, proving the two objects are independent.

1const order = { id: "tea", count: 3 };2const copy = structuredClone(order);3copy.count = 4;4 5console.log(order.count);6console.log(copy.count);7 8// Clone creates another value; it does not share the original plain object.

Line 1 creates an order. Line 2 makes the clone, and line 3 changes that clone. Lines 5 and 6 still print 3 then 4. Cloning is useful when sender and receiver should each safely change their own copy.

1const buffer = new ArrayBuffer(8);2const moved = structuredClone(buffer, { transfer: [buffer] });3 4console.log(buffer.byteLength);5console.log(moved.byteLength);

Line 1 creates eight bytes. Line 2 transfers ownership. Line 4 prints 0 because the original is detached. Line 5 prints 8 because the moved buffer owns the bytes.

1const buffer = new ArrayBuffer(8);Run2const moved = structuredClone(buffer, { transfer: [buffer] });3 4console.log(buffer.byteLength);5console.log(moved.byteLength);

1const cart = { save() {} };2 3try {4  structuredClone(cart);5} catch (error) {6  console.log(error.name);7}

Line 1 creates an object containing a function. Line 4 tries to clone it. The catch block prints DataCloneError. Functions and DOM nodes cannot be cloned because their behavior or platform identity is not plain transferable data.

1const parentSymbol = Symbol.for("cart-status");2const otherRealmSymbol = Symbol.for("cart-status");3 4console.log(parentSymbol === otherRealmSymbol);5 6// Symbol.for uses an agent-wide registry, unlike Array constructors per realm.

Lines 1 and 2 ask the global symbol registry for the same key. Line 4 prints true. This is a useful exception to remember: realms have separate Array constructors, while Symbol.for uses the registry shared by the JavaScript agent.

Practical choices

First ask whether two documents truly need direct access. Same-origin integration can share objects, but it also creates a tight dependency between two global environments. A message boundary makes the data contract visible and works when origins differ.

For values from an extension, iframe, or another window, avoid checking application types only with instanceof. Prefer realm-safe tests such as Array.isArray, explicit discriminant properties such as type, or schema validation for untrusted messages.

• Use postMessage with an exact target origin for cross-origin communication.
• Validate received origin and message shape before using a message.
• Transfer large buffers when one receiver should own them; clone when both sides need independent data.
• Use Array.isArray when arrays may come from another realm.

Common misconceptions

• “An iframe is just visual.” It has a document, a global object, and its own realm.
• “window is always one object.” A cross-frame window reference is normally a WindowProxy that can survive navigation.
• “instanceof recognizes every array.” It compares one constructor's prototype, so realm boundaries matter.
• “Same origin means no boundaries.” It permits direct access but realms and constructor identity remain separate.
• “structuredClone serializes everything.” Functions and DOM nodes produce DataCloneError.

Practice exercises

Array.isArray(value)

const buffer = new ArrayBuffer(4);
const moved = structuredClone(buffer, { transfer: [buffer] });
console.log(buffer.byteLength, moved.byteLength);

frame.contentWindow.postMessage(message, targetOrigin);

Check your understanding

Use the quiz to separate constructor identity, browsing-context identity, origin checks, and data movement.

Key takeaways

• Every document global has a realm with its own built-ins.
• WindowProxy is the stable reference for a browsing context across navigation.
• Across realms, instanceof can be false while Array.isArray is true.
• Most code only needs current realm and an object's relevant realm.
• Same-origin frames can access documents directly; cross-origin frames should communicate with postMessage.
• Structured clone copies supported data, while transfer moves ownership of values such as ArrayBuffer.

Coming next: The browser security model, where the same-origin policy, isolation, and browser process boundaries protect those separate worlds.