# Portals

## Draft Community Group Report, 1 January 1970

This version:
  https://wicg.github.io/portals/
Editors:
  Jeremy Roman (Google)
  Lucas Gadani (Google)

Copyright © 1970 the Contributors to the Portals Specification, published by the Web Platform Incubator Community Group under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.

## Abstract

This specification defines a mechanism that allows for rendering of, and seamless navigation to, embedded content.

## Status of this document

This specification was published by the Web Platform Incubator Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

## 1. Introduction

This section is non-normative.

This specification extends [HTML] to define a new kind of top-level browsing context, which can be embedded in another document, and a mechanism for replacing the contents of another top-level browsing context with the previously embedded context.

## 2. Concepts

Every browsing context has a portal state, which may be "`none`" (the default), "`portal`" or "`orphaned`". A nested browsing context always has the portal state "`none`".

Briefly, these correspond to:

- "`portal`": top-level browsing contexts embedded in a `portal` element

- "`orphaned`": top-level browsing contexts which have run `activate` but have not (yet) been adopted

- "`none`": all other browsing contexts

A top-level "`none`" context can become "`orphaned`" by activating another context. An "`orphaned`" context can be adopted to become a "`portal`" context. A "`portal`" context can become a "`none`" context by being activated by its host browsing context.

A browsing context can be closed while in any of these states.

A portal browsing context is a browsing context whose portal state is "`portal`".

The host element of a portal browsing context is a `portal` element which embeds its rendered output and receives messages sent from the portal browsing context.

A `portal` element may only be a host element while it is browsing-context connected or during the dispatch of the `portalactivate` event from which it was obtained using `adoptPredecessor()`.

The host browsing context of a portal browsing context is its host element's document's browsing context.

The portal task source is a task source used for tasks related to the portal lifecycle and communication between a portal browsing context and its host browsing context.

To activate a portal browsing context successorBrowsingContext in place of predecessorBrowsingContext with data serializeWithTransferResult and promise promise, run the following steps in parallel:

1. Assert: The portal state of predecessorBrowsingContext is "`none`".

2. Set the host element of successorBrowsingContext to null.

   User agents should, however, attempt to preserve the rendering of the guest browsing context until predecessorBrowsingContext has been replaced with successorBrowsingContext in the rendering.

   Note: This is intended to avoid a visual glitch, such as a "white flash", where the guest browsing context briefly disappears.

3. Set the portal state of predecessorBrowsingContext to "`orphaned`".

4. Update the user interface to replace predecessorBrowsingContext with successorBrowsingContext (e.g., by updating the tab/window contents and browser chrome).

5. Let successorWindow be successorBrowsingContext’s associated `WindowProxy`'s [[Window]] internal slot value.

6. Queue a task from the portal task source to the event loop associated with successorWindow to run the following steps:

   1. Assert: The portal state of successorBrowsingContext is "`portal`".

   2. Set the portal state of successorBrowsingContext to "`none`".

   3. Let targetRealm be successorWindow’s realm.

   4. Let deserializeRecord be StructuredDeserializeWithTransfer(serializeWithTransferResult, targetRealm), and let dataClone be deserializeRecord.[[Deserialized]].

      If this throws an exception, catch it, and let dataClone be null instead.

   5. Let event be the result of creating an event using `PortalActivateEvent` and targetRealm.

   6. Initialize event’s `type` attribute to `portalactivate`.

   7. Initialize event’s `data` attribute to dataClone.

   8. Set event’s predecessor browsing context to predecessorBrowsingContext.

   9. Set event’s successor window to successorWindow.

   10. Set event’s activation promise to promise.

   11. Dispatch event to successorWindow.

   12. Let adoptedPredecessorElement be event’s adopted predecessor element.

   13. If adoptedPredecessorElement is not null, then:

       1. Set adoptedPredecessorElement’s just-adopted flag to false.

       2. If adoptedPredecessorElement may not have a guest browsing context and its guest browsing context is not null, then discard it.

          This unceremoniously discards the browsing context, as if the element had been removed from the document after previously being attached. This is distinct from the case where the predecessor was never adopted, below, which closes the browsing context, which dispatches the `unload` event, somewhat similarly to if it had performed an ordinary navigation.

          Typically authors would not call `adoptPredecessor()` unless they intend to insert it into the document before the just-adopted flag becomes false.

   14. Otherwise:

       1. Queue a task from the portal task source to the event loop associated with predecessorBrowsingContext to resolve promise with undefined.

       2. Close predecessorBrowsingContext.

          The user agent should not ask the user for confirmation during the prompt to unload step (and so the browsing context should be discarded).

- portal-activate-event.html (live test) (source)
- portals-host-hidden-after-activation.html (live test) (source)

In the case that structured deserialization throws, it may be useful to do something else to indicate it, rather than simply providing null data.
We need to specify how the session history of each browsing context is affected by activation, and supply non-normative text that explains how these histories are expected to be presented to the user.
To adopt the predecessor browsing context predecessorBrowsingContext in successorWindow, run the following steps:

1. Let document be the document of successorWindow.

2. Let portalElement be the result of creating an element given document, `portal`, and the HTML namespace.

3. Set portalElement’s just-adopted flag to true.

4. Assert: portalElement is an `HTMLPortalElement`.

5. Queue a task from the portal task source to the event loop associated with predecessorBrowsingContext to run the following steps:

   1. Assert: The portal state of predecessorBrowsingContext is "`orphaned`".

   2. Set the portal state of predecessorBrowsingContext to "`portal`", and set the host element of predecessorBrowsingContext to portalElement.

6. Return portalElement.

Since the task to set the portal state, and thus expose the `PortalHost` object, is queued first, and from the same task source, it is exposed at the time the activation promise returned from `activate(options)` is resolved.

    // In the successor document.
    onportalactivate = event => {
      // The predecessor document is adopted into a <portal> element...
      document.body.appendChild(event.adoptPredecessor());
    });

    // In the predecessor document.
    portalElement.activate().then(() => {
      // ...and it is guaranteed to observe that change by the time the
      // activation promise resolves.
      console.assert(window.portalHost instanceof PortalHost);
    });

## 3. API

### 3.1. The `portal` element

A `portal` element allows for a portal browsing context to be embedded in an HTML document.

- portals-rendering.html (live test) (source)

A `portal` element portalElement has a guest browsing context, which is the portal browsing context whose host element is portalElement, or null if no such browsing context exists.

A `portal` element has a just-adopted flag, which is a boolean and is initially false. It is set during dispatch of the `portalactivate` event.

The `src` attribute gives the URL of a page that the guest browsing context is to contain. The attribute, if present, must be a valid non-empty URL potentially surrounded by spaces.

The `referrerpolicy` attribute is a referrer policy attribute. Its purpose is to set the referrer policy used when setting the source URL of a portal element. [REFERRER-POLICY]

A `portal` is similar to an `iframe`, in that it allows another browsing context to be embedded. However, the portal browsing context hosted by a `portal` is part of a separate browsing context group, and thus a separate agent. The user agent is therefore free to use a separate event loop for the browsing contexts, even if they are same origin-domain.

    [Exposed=Window, HTMLConstructor]
    interface HTMLPortalElement : HTMLElement {
        [CEReactions] attribute USVString src;
        [CEReactions] attribute DOMString referrerPolicy;

        [NewObject] Promise<void> activate(optional PortalActivateOptions options);
        void postMessage(any message, DOMString targetOrigin, optional sequence<object> transfer = []);
        void postMessage(any message, optional WindowPostMessageOptions options);

        attribute EventHandler onmessage;
        attribute EventHandler onmessageerror;
    };

    dictionary PortalActivateOptions {
        any data = null;
        sequence<object> transfer = [];
    };

The `src` IDL attribute must reflect the `src` content attribute.

The `referrerPolicy` IDL attribute must reflect the `referrerpolicy` content attribute, limited to only known values.

The `activate(options)` method must run these steps:

1. Let portalBrowsingContext be the guest browsing context of this.

2. If portalBrowsingContext is null, throw an "`InvalidStateError`" `DOMException`.

   - portals-activate-no-browsing-context.html (live test) (source)

3. Let predecessorBrowsingContext be the browsing context of this's document.

4. If predecessorBrowsingContext is null, throw an "`InvalidStateError`" `DOMException`.

5. If the portal state of predecessorBrowsingContext is not "`none`", throw an "`InvalidStateError`" `DOMException`.

   Note: This means that a `portal` element inside a portal browsing context cannot be activated.

6. Let serializeWithTransferResult be StructuredSerializeWithTransfer(options["`data`"], options["`transfer`"]). Rethrow any exceptions.

7. Let promise be a new promise.

8. Run the steps to activate portalBrowsingContext in place of predecessorBrowsingContext with data serializeWithTransferResult and promise promise.

9. Return promise.

- portal-activate-data.html (live test) (source)
- portals-activate-inside-iframe.html (live test) (source)
- portals-activate-inside-portal.html (live test) (source)
- portals-activate-resolution.html (live test) (source)
- portals-activate-twice.html (live test) (source)

The `postMessage(message, targetOrigin, transfer)` method must run these steps:

1. Let options be « "`targetOrigin`" → targetOrigin, "`transfer`" → transfer ».

2. Run the steps for `postMessage`(message, options).

The `postMessage(message, options)` method must run these steps:

1. Let portalBrowsingContext be the guest browsing context of this.

2. If portalBrowsingContext is null, throw an "`InvalidStateError`" `DOMException`.

3. Let settings be the relevant settings object of this.

4. Let origin be the serialization of settings’s origin.

5. Let targetOrigin be options["`targetOrigin`"].

6. If targetOrigin is a single U+002F SOLIDUS character (/), then set targetOrigin to the origin of settings.

7. Otherwise, if targetOrigin is not a single U+002A ASTERISK character (*), then:

   1. Let parsedURL be the result of running the URL parser on targetOrigin.

   2. If parsedURL is failure, then throw a "`SyntaxError`" `DOMException`.

   3. Set targetOrigin to parsedURL’s origin.

8. Let transfer be options["`transfer`"].

9. Let serializeWithTransferResult be StructuredSerializeWithTransfer(message, transfer). Rethrow any exceptions.

10. Queue a task from the portal task source to the event loop of portalBrowsingContext to run the following steps:

    1. If targetOrigin is not a single literal U+002A ASTERISK character (*) and the origin of portalBrowsingContext’s active document is not same origin with targetOrigin, then abort these steps.

    2. Let targetWindow be portalBrowsingContext’s associated `WindowProxy`'s [[Window]] internal slot value.

    3. Let portalHost be the targetWindow’s portal host object.

    4. Let targetRealm be the targetWindow’s realm.

    5. Let deserializeRecord be StructuredDeserializeWithTransfer(serializeWithTransferResult, targetRealm).

       If this throws an exception, catch it, fire an event named `messageerror` at portalHost using `MessageEvent` with the `origin` attribute initialized to origin and the `source` attribute initialized to portalHost, then abort these steps.

    6. Let messageClone be deserializeRecord.[[Deserialized]].

    7. Let newPorts be a new frozen array consisting of all `MessagePort` objects in deserializeRecord.[[TransferredValues]], if any, maintaining their relative order.

    8. Fire an event named `message` at portalHost using `MessageEvent`, with the `origin` attribute initialized to origin, the `source` attribute initialized to portalHost, the `data` attribute initialized to messageClone, and the `ports` attribute initialized to newPorts.

- portals-post-message.sub.html (live test) (source)

To determine whether a `portal` element may have a guest browsing context, run the following steps:

1. If element’s document's browsing context is not a top-level browsing context, then return false.

   - portals-nested.html (live test) (source)

   The user agent may choose to emit a warning if the author attempts to use a `portal` element in a nested browsing context, as this is not supported.

2. If element is browsing-context connected, then return true.

3. If element’s just-adopted flag is true, then return true.

4. Return false.

To close a `portal` element element, run the following steps:

1. If element’s guest browsing context is not null, then close it.

   The user agent should not ask the user for confirmation during the prompt to unload step (and so the browsing context should be discarded).

To set the source URL of a `portal` element element, run the following steps:

1. Assert: element may have a guest browsing context.

2. Let hostBrowsingContext be element’s document's browsing context.

3. Assert: hostBrowsingContext is a top-level browsing context.

4. If element has no `src` attribute specified, or its value is the empty string, then close element and return.

5. Parse the value of the `src` attribute. If that is not successful, then close element and return.

   Otherwise, let url be the resulting URL record.

6. If the scheme of url is not an HTTP(S) scheme, then close element and return.

7. If element’s guest browsing context is null, then run the following steps:

   1. Let newBrowsingContext be the result of creating a new top-level browsing context.

   2. Set the portal state of newBrowsingContext to "`portal`", and set the host element of newBrowsingContext to element.

8. Let guestBrowsingContext be element’s guest browsing context.

9. Assert: guestBrowsingContext is not null.

10. Let resource be a new request whose URL is url and whose referrer policy is the current state of element’s `referrerpolicy` content attribute.

11. Navigate guestBrowsingContext to resource.

Unlike an `iframe` element, a `portal` element supports a state where it has no associated browsing context. This is the initial state of a `portal` element (i.e., it has no initial `about:blank` document; instead it navigates directly to the first parsable URL assigned to it).

Similarly, a `portal` element responds to an unparsable `src` URL by closing its browsing context, rather than by navigating to `about:blank`.

- portal-non-http-navigation.html (live test) (source)
- portals-cross-origin-load.sub.html (live test) (source)
- portals-referrer.html (live test) (source)
- portals-referrer-inherit-header.html (live test) (source)
- portals-referrer-inherit-meta.html (live test) (source)

Whenever a `portal` element element has its `src` attribute set, changed, or removed, run the following steps:

1. If element may have a guest browsing context, then set the source URL of element.

Whenever a `portal` element element becomes browsing-context connected, run the following steps:

1. If element may not have a guest browsing context, then abort these steps.

2. If element’s guest browsing context is not null, then abort these steps.

   This ensures that a newly adopted `portal` element can be inserted into the document without navigating it.

3. Set the source URL of element.

Whenever a `portal` element element becomes browsing-context disconnected, run the following steps:

1. If element may not have a guest browsing context and its guest browsing context is not null, then discard it.

It might be convenient to not immediately detach the portal element, but instead to do so in a microtask. This would allow developers to reinsert the `portal` element without losing its browsing context.

Whenever a `portal` element element is adopted, run the following steps:

1. Let guestBrowsingContext be element’s guest browsing context.

2. If guestBrowsingContext is null, then abort these steps.

3. Discard guestBrowsingContext.

In particular, this means a `portal` element loses its guest browsing context if it is moved to the active document of a nested browsing context.

Similarly, the steps when a `portal` element’s source URL is set prevent elements from creating a new guest browsing context while inside such documents.

It is therefore impossible to embed a portal browsing context in a nested browsing context.

The following events are dispatched on `HTMLPortalElement` objects:

Event name | Interface | Dispatched when
--- | --- | ---
`message` | `MessageEvent` | A message is received by the object, and deserialization does not throw an exception.
`messageerror` | `MessageEvent` | A message is received by the object, but deserialization throws an exception.

The `portal` element exposes `onmessage` and `onmessageerror` as event handler content attributes.

- htmlportalelement-event-handler-content-attributes.html (live test) (source)

### 3.2. The `PortalHost` interface

The portal host object of a `Window` is a `PortalHost`.

The portal host object can be used to communicate with the host browsing context. Its operations throw if used while its context is not a portal browsing context (i.e. there is no host). It is not accessible via `window.portalHost` at such times.

    [Exposed=Window]
    interface PortalHost : EventTarget {
        void postMessage(any message, DOMString targetOrigin, optional sequence<object> transfer = []);
        void postMessage(any message, optional WindowPostMessageOptions options);

        attribute EventHandler onmessage;
        attribute EventHandler onmessageerror;
    };

The `postMessage(message, targetOrigin, transfer)` method must run these steps:

1. Let options be « "`targetOrigin`" → targetOrigin, "`transfer`" → transfer ».

2. Run the steps for `postMessage`(message, options).

The `postMessage(message, options)` method must run these steps:

1. Let settings be the relevant settings object of this.

2. Let browsingContext be the responsible browsing context of settings.

3. If browsingContext has a portal state other than "`portal`", throw an "`InvalidStateError`" `DOMException`.

   Note: This roughly means that it has not yet been activated, as far as this event loop has been told. It is possible that this browsing context will be activated in parallel to this message being sent; in such cases, messages may not be delivered.

4. Let origin be the serialization of settings’s origin.

5. Let targetOrigin be options["`targetOrigin`"].

6. If targetOrigin is a single U+002F SOLIDUS character (/), then set targetOrigin to the origin of settings.

7. Otherwise, if targetOrigin is not a single U+002A ASTERISK character (*), then:

   1. Let parsedURL be the result of running the URL parser on targetOrigin.

   2. If parsedURL is failure, then throw a "`SyntaxError`" `DOMException`.

   3. Set targetOrigin to parsedURL’s origin.

8. Let transfer be options["`transfer`"].

9. Let serializeWithTransferResult be StructuredSerializeWithTransfer(message, transfer). Rethrow any exceptions.

10. Let hostElement be the host element of browsingContext.

11. Let hostBrowsingContext be the host browsing context of browsingContext.

12. Queue a task from the portal task source to the event loop associated with hostBrowsingContext to run the following steps:

    1. If browsingContext is not the guest browsing context of hostElement, then abort these steps.

       Note: This might happen if this event loop had a queued task to deliver a message, but it was not executed before the portal was activated. In such cases, the message is not delivered.

    2. Let targetSettings be the relevant settings object of hostElement.

    3. If targetOrigin is not a single literal U+002A ASTERISK character (*) and targetSettings’s origin is not same origin with targetOrigin, then abort these steps.

    4. Let targetRealm be targetSettings’s realm.

    5. Let deserializeRecord be StructuredDeserializeWithTransfer(serializeWithTransferResult, targetRealm).

       If this throws an exception, catch it, fire an event named `messageerror` at element using `MessageEvent` with the `origin` attribute initialized to origin and the `source` attribute initialized to element.

    6. Let messageClone be deserializeRecord.[[Deserialized]].

    7. Let newPorts be a new frozen array consisting of all `MessagePort` objects in deserializeRecord.[[TransferredValues]], if any, maintaining their relative order.

    8. Fire an event named `message` at the element using `MessageEvent`, with the `origin` attribute initialized to origin, the `source` attribute initialized to element, the `data` attribute initialized to messageClone, and the `ports` attribute initialized to newPorts.

- portals-host-post-message.sub.html (live test) (source)

The following events are dispatched on `PortalHost` objects:

Event name | Interface | Dispatched when
--- | --- | ---
`message` | `MessageEvent` | A message is received by the object, and deserialization does not throw an exception.
`messageerror` | `MessageEvent` | A message is received by the object, but deserialization throws an exception.

### 3.3. The `PortalActivateEvent` interface

    [Constructor(DOMString type, optional PortalActivateEventInit eventInitDict), Exposed=Window]
    interface PortalActivateEvent : Event {
        readonly attribute any data;
        HTMLPortalElement adoptPredecessor();
    };

    dictionary PortalActivateEventInit : EventInit {
        any data = null;
    };

A `PortalActivateEvent` has an associated predecessor browsing context, which is a top-level browsing context or null, a successor window, which is a `Window`, an activation promise, which is a promise, and a adopted predecessor element, which is a `portal` element or null.

The event constructing steps for `PortalActivateEvent`, given an event, are as follows:

1. Set event’s predecessor browsing context to null.

2. Set event’s successor window to null.

3. Set event’s adopted predecessor element to null.

- portal-activate-event-constructor.html (live test) (source)

The `adoptPredecessor()` method must run these steps:

1. If this's adopted predecessor element is not null, throw an "`InvalidStateError`" `DOMException`.

2. Let predecessorBrowsingContext be this's predecessor browsing context.

3. Let successorWindow be this's successor window.

4. Run the steps to adopt the predecessor browsing context predecessorBrowsingContext in successorWindow, and let adoptedPredecessorElement be the result.

5. Set this's adopted predecessor element to adoptedPredecessorElement.

6. Queue a task from the portal task source to the event loop associated with predecessorBrowsingContext to resolve this's activation promise with undefined.

   Note: Queuing this immediately makes it possible to send messages to the adopted portal during dispatch of the `portalactivate` event without ordering issues between the task to resolve the activation promise and the task to deliver the message.

7. Return adoptedPredecessorElement.

- portals-adopt-predecessor.html (live test) (source)

### 3.4. Miscellaneous extensions

The `MessageEventSource` union is extended to include the new interfaces which can produce `MessageEvent` events.

    typedef (WindowProxy or MessagePort or ServiceWorker or HTMLPortalElement or PortalHost) MessageEventSource;

A `PortalHost` is exposed at times when the window may be in a portal browsing context.

    partial interface Window {
        readonly attribute PortalHost? portalHost;
    };

    partial interface mixin WindowEventHandlers {
        attribute EventHandler onportalactivate;
    };

The `portalHost` attribute’s getter must run the following steps:

1. Let context be this's browsing context.

2. If context is null or the portal state of context is not "`portal`", then return null.

3. Return this's portal host object.

- portals-host-exposure.sub.html (live test) (source)
- portals-host-null.html (live test) (source)

The following events are dispatched on `Window` objects:

Event name | Interface | Dispatched when
--- | --- | ---
`portalactivate` | `PortalActivateEvent` | The window is associated with a new top-level browsing context due to activation of its portal browsing context.

Like other event handler IDL attributes in the `WindowEventHandlers` interface mixin, `onportalactivate` is exposed on all `body` and `frameset` elements as a event handler content attribute.

## 4. Security Considerations

We should expand this section further.

### 4.1. Overview

This section is non-normative.

In general, a portal browsing context should respect policies that would apply to a nested browsing context, e.g. that would restrict whether a document can be embedded in a document from another origin.

### 4.2. Integration with Content Security Policy

This specification integrates with [CSP] as follows.

The algorithm for determining the effective directive for a request is modified by prepending the following:

1. If request’s initiator is "", its destination is "`document`", and its target browsing context is a portal browsing context, return `frame-src`.

The frame-ancestors Navigation Response Check is modified as follows:

1. Replace all references to "nested browsing context" with "nested browsing context or portal browsing context".

2. Replace all references to "parent browsing context" with "parent browsing context or host browsing context".

`activate(options)` should also respect the CSP navigate-to directive.

### 4.3. Integration with RFC 7034

This specification integrates with [RFC7034], which defines the `X-Frame-Options` HTTP header, as follows.

If a browser receives content with this header field in response to a navigation request whose target browsing context is a portal browsing context, then the browser must apply the rules in [RFC7034] as though it were to be displayed in a frame in the host browsing context instead and as though the origin of the top-level browsing context topLevelBrowsingContext were the origin of the result of the following algorithm:

1. While topLevelBrowsingContext is a portal browsing context:

   1. Set topLevelBrowsingContext to its host browsing context.

2. Return topLevelBrowsingContext.

### 4.4. Integration with Fetch Metadata Request Headers

This specification integrates with [FETCH-METADATA] as follows.

The effect of this is that the request for a document in a portal browsing context will contain the following HTTP header, as though it were in a nested browsing context.

        Sec-Fetch-Mode: nested-navigate

Even though no spec patches are required to do so, implementations must also send the appropriate fetch metadata headers as it would if the load were occurring in an `iframe` element.

The algorithm to set the Sec-Fetch-Mode header for a request r is modified as follows:

1. Where the algorithm checks whether r’s reserved client's target browsing context is a nested browsing context, check instead whether it is a nested browsing context or a portal browsing context.

## Conformance

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with `class="example"`, like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with `class="note"`, like this:

Note, this is an informative note.

## Index

### Terms defined by this specification

- activate(), in §3.1
- activate a portal browsing context, in §2
- activate(options), in §3.1
- activation promise, in §3.3
- adopted predecessor element, in §3.3
- adoptPredecessor(), in §3.3
- adopt the predecessor browsing context, in §2
- close a portal element, in §3.1
- data
  - attribute for PortalActivateEvent, in §3.3
  - dict-member for PortalActivateEventInit, in §3.3
  - dict-member for PortalActivateOptions, in §3.1
- guest browsing context, in §3.1
- host browsing context, in §2
- host element, in §2
- HTMLPortalElement, in §3.1
- just-adopted flag, in §3.1
- may have a guest browsing context, in §3.1
- message
  - event for HTMLPortalElement, in §3.1
  - event for PortalHost, in §3.2
- messageerror
  - event for HTMLPortalElement, in §3.1
  - event for PortalHost, in §3.2
- MessageEventSource, in §3.4
- onmessage
  - attribute for HTMLPortalElement, in §3.1
  - attribute for PortalHost, in §3.2
- onmessageerror
  - attribute for HTMLPortalElement, in §3.1
  - attribute for PortalHost, in §3.2
- onportalactivate, in §3.4
- portal, in §3.1
- portalactivate, in §3.4
- PortalActivateEvent, in §3.3
- PortalActivateEventInit, in §3.3
- PortalActivateOptions, in §3.1
- portal browsing context, in §2
- PortalHost, in §3.2
- portalHost, in §3.4
- portal host object, in §3.2
- portal state, in §2
- portal task source, in §2
- postMessage(message)
  - method for HTMLPortalElement, in §3.1
  - method for PortalHost, in §3.2
- postMessage(message, options)
  - method for HTMLPortalElement, in §3.1
  - method for PortalHost, in §3.2
- postMessage(message, targetOrigin)
  - method for HTMLPortalElement, in §3.1
  - method for PortalHost, in §3.2
- postMessage(message, targetOrigin, transfer)
  - method for HTMLPortalElement, in §3.1
  - method for PortalHost, in §3.2
- predecessor browsing context, in §3.3
- referrerPolicy, in §3.1
- referrerpolicy, in §3.1
- set the source URL of a portal element, in §3.1
- src
  - attribute for HTMLPortalElement, in §3.1
  - element-attr for portal, in §3.1
- successor window, in §3.3
- transfer, in §3.1

https://w3c.github.io/webappsec-csp/#navigate-to Referenced in:

- 4.2. Integration with Content Security Policy

https://dom.spec.whatwg.org/#event Referenced in:

- 3.3. The PortalActivateEvent interface

https://dom.spec.whatwg.org/#dictdef-eventinit Referenced in:

- 3.3. The PortalActivateEvent interface

https://dom.spec.whatwg.org/#eventtarget Referenced in:

- 3.2. The PortalHost interface

https://dom.spec.whatwg.org/#concept-node-adopt-ext Referenced in:

- 3.1. The portal element

https://dom.spec.whatwg.org/#concept-create-element Referenced in:

- 2. Concepts

https://dom.spec.whatwg.org/#concept-event-create Referenced in:

- 2. Concepts

https://dom.spec.whatwg.org/#concept-event-dispatch Referenced in:

- 2. Concepts

https://dom.spec.whatwg.org/#concept-event-constructor-ext Referenced in:

- 3.3. The PortalActivateEvent interface

https://dom.spec.whatwg.org/#concept-event-fire Referenced in:

- 3.1. The portal element (2)
- 3.2. The PortalHost interface (2)

https://dom.spec.whatwg.org/#concept-node-document Referenced in:

- 2. Concepts
- 3.1. The portal element (2) (3)

https://dom.spec.whatwg.org/#concept-reflect Referenced in:

- 3.1. The portal element (2)

https://dom.spec.whatwg.org/#dom-event-type Referenced in:

- 2. Concepts

http://tc39.github.io/ecma262/#sec-agents Referenced in:

- 3.1. The portal element

http://tc39.github.io/ecma262/#sec-promise-objects Referenced in:

- 3.1. The portal element
- 3.3. The PortalActivateEvent interface

https://fetch.spec.whatwg.org/#concept-request-destination Referenced in:

- 4.2. Integration with Content Security Policy

https://fetch.spec.whatwg.org/#http-scheme Referenced in:

- 3.1. The portal element

https://fetch.spec.whatwg.org/#concept-request-initiator Referenced in:

- 4.2. Integration with Content Security Policy

https://fetch.spec.whatwg.org/#concept-request Referenced in:

- 3.1. The portal element

https://fetch.spec.whatwg.org/#concept-request-referrer-policy Referenced in:

- 3.1. The portal element

https://fetch.spec.whatwg.org/#concept-request-url Referenced in:

- 3.1. The portal element

https://fetch.spec.whatwg.org/#concept-request-reserved-client Referenced in:

- 4.4. Integration with Fetch Metadata Request Headers

https://html.spec.whatwg.org/multipage/custom-elements.html#cereactions Referenced in:

- 3.1. The portal element (2)

https://html.spec.whatwg.org/multipage/webappapis.html#eventhandler Referenced in:

- 3.1. The portal element (2)
- 3.2. The PortalHost interface (2)
- 3.4. Miscellaneous extensions

https://html.spec.whatwg.org/multipage/dom.html#htmlconstructor Referenced in:

- 3.1. The portal element

https://html.spec.whatwg.org/multipage/dom.html#htmlelement Referenced in:

- 3.1. The portal element

https://html.spec.whatwg.org/multipage/comms.html#messageevent Referenced in:

- 3.1. The portal element (2) (3) (4)
- 3.2. The PortalHost interface (2) (3) (4)
- 3.4. Miscellaneous extensions

https://html.spec.whatwg.org/multipage/web-messaging.html#messageport Referenced in:

- 3.1. The portal element
- 3.2. The PortalHost interface
- 3.4. Miscellaneous extensions

https://html.spec.whatwg.org/multipage/web-messaging.html#postmessageoptions Referenced in:

- 3.1. The portal element
- 3.2. The PortalHost interface

https://html.spec.whatwg.org/multipage/structured-data.html#structureddeserializewithtransfer Referenced in:

- 2. Concepts
- 3.1. The portal element
- 3.2. The PortalHost interface

https://html.spec.whatwg.org/multipage/structured-data.html#structuredserializewithtransfer Referenced in:

- 3.1. The portal element (2)
- 3.2. The PortalHost interface

https://html.spec.whatwg.org/multipage/window-object.html#window Referenced in:

- 3.2. The PortalHost interface
- 3.3. The PortalActivateEvent interface
- 3.4. Miscellaneous extensions (2)

https://html.spec.whatwg.org/multipage/webappapis.html#windoweventhandlers Referenced in:

- 3.4. Miscellaneous extensions (2)

https://html.spec.whatwg.org/multipage/window-object.html#windowpostmessageoptions Referenced in:

- 3.1. The portal element (2) (3) (4)
- 3.2. The PortalHost interface (2) (3) (4)

https://html.spec.whatwg.org/multipage/window-object.html#windowproxy Referenced in:

- 2. Concepts
- 3.1. The portal element
- 3.4. Miscellaneous extensions

https://html.spec.whatwg.org/multipage/browsers.html#active-document Referenced in:

- 3.1. The portal element (2)

https://html.spec.whatwg.org/multipage/window-object.html#concept-document-window Referenced in:

- 2. Concepts

https://html.spec.whatwg.org/multipage/infrastructure.html#becomes-browsing-context-connected Referenced in:

- 3.1. The portal element

https://html.spec.whatwg.org/multipage/infrastructure.html#becomes-browsing-context-disconnected Referenced in:

- 3.1. The portal element

https://html.spec.whatwg.org/multipage/sections.html#the-body-element Referenced in:

- 3.4. Miscellaneous extensions

https://html.spec.whatwg.org/multipage/window-object.html#window-bc Referenced in:

- 3.4. Miscellaneous extensions

https://html.spec.whatwg.org/multipage/browsers.html#browsing-context-group Referenced in:

- 3.1. The portal element

https://html.spec.whatwg.org/multipage/infrastructure.html#browsing-context-connected Referenced in:

- 2. Concepts
- 3.1. The portal element

https://html.spec.whatwg.org/multipage/window-object.html#close-a-browsing-context Referenced in:

- 2. Concepts (2) (3)
- 3.1. The portal element (2)

https://html.spec.whatwg.org/multipage/browsers.html#creating-a-new-top-level-browsing-context Referenced in:

- 3.1. The portal element

https://html.spec.whatwg.org/multipage/comms.html#dom-messageevent-data Referenced in:

- 3.1. The portal element
- 3.2. The PortalHost interface

https://html.spec.whatwg.org/multipage/window-object.html#a-browsing-context-is-discarded Referenced in:

- 2. Concepts (2) (3)
- 3.1. The portal element (2) (3)

https://html.spec.whatwg.org/multipage/browsers.html#concept-document-bc Referenced in:

- 3.1. The portal element

https://html.spec.whatwg.org/multipage/webappapis.html#event-handler-content-attributes Referenced in:

- 3.1. The portal element
- 3.4. Miscellaneous extensions

https://html.spec.whatwg.org/multipage/webappapis.html#event-handler-idl-attributes Referenced in:

- 3.4. Miscellaneous extensions

https://html.spec.whatwg.org/multipage/webappapis.html#event-loop Referenced in:

- 2. Concepts (2) (3)
- 3.1. The portal element (2)
- 3.2. The PortalHost interface (2) (3)
- 3.3. The PortalActivateEvent interface

https://html.spec.whatwg.org/multipage/obsolete.html#frameset Referenced in:

- 3.4. Miscellaneous extensions

https://html.spec.whatwg.org/multipage/iframe-embed-object.html#the-iframe-element Referenced in:

- 3.1. The portal element (2)
- 4.4. Integration with Fetch Metadata Request Headers

https://html.spec.whatwg.org/multipage/infrastructure.html#in-parallel Referenced in:

- 2. Concepts

https://html.spec.whatwg.org/multipage/common-dom-interfaces.html#limited-to-only-known-values Referenced in:

- 3.1. The portal element

https://html.spec.whatwg.org/multipage/browsing-the-web.html#navigate Referenced in:

- 3.1. The portal element

https://html.spec.whatwg.org/multipage/browsers.html#nested-browsing-context Referenced in:

- 2. Concepts
- 3.1. The portal element (2) (3)
- 4.1. Overview
- 4.2. Integration with Content Security Policy (2)
- 4.4. Integration with Fetch Metadata Request Headers (2) (3)

https://html.spec.whatwg.org/multipage/webappapis.html#concept-settings-object-origin Referenced in:

- 3.1. The portal element
- 3.2. The PortalHost interface (2)

https://html.spec.whatwg.org/multipage/browsers.html#parent-browsing-context Referenced in:

- 4.2. Integration with Content Security Policy (2)

https://html.spec.whatwg.org/multipage/urls-and-fetching.html#parse-a-url Referenced in:

- 3.1. The portal element

https://html.spec.whatwg.org/multipage/comms.html#dom-messageevent-ports Referenced in:

- 3.1. The portal element
- 3.2. The PortalHost interface

https://html.spec.whatwg.org/multipage/browsing-the-web.html#prompt-to-unload-a-document Referenced in:

- 2. Concepts
- 3.1. The portal element

https://html.spec.whatwg.org/multipage/webappapis.html#queue-a-task Referenced in:

- 2. Concepts (2) (3)
- 3.1. The portal element
- 3.2. The PortalHost interface
- 3.3. The PortalActivateEvent interface

https://html.spec.whatwg.org/multipage/webappapis.html#concept-global-object-realm Referenced in:

- 2. Concepts
- 3.1. The portal element

https://html.spec.whatwg.org/multipage/urls-and-fetching.html#referrer-policy-attribute Referenced in:

- 3.1. The portal element

https://html.spec.whatwg.org/multipage/webappapis.html#relevant-settings-object Referenced in:

- 3.1. The portal element
- 3.2. The PortalHost interface (2)

https://html.spec.whatwg.org/multipage/webappapis.html#responsible-browsing-context Referenced in:

- 3.2. The PortalHost interface

https://html.spec.whatwg.org/multipage/urls-and-fetching.html#resulting-url-record Referenced in:

- 3.1. The portal element

https://html.spec.whatwg.org/multipage/origin.html#same-origin Referenced in:

- 3.1. The portal element
- 3.2. The PortalHost interface

https://html.spec.whatwg.org/multipage/origin.html#same-origin-domain Referenced in:

- 3.1. The portal element

https://html.spec.whatwg.org/multipage/origin.html#ascii-serialisation-of-an-origin Referenced in:

- 3.1. The portal element
- 3.2. The PortalHost interface

https://html.spec.whatwg.org/multipage/history.html#session-history Referenced in:

- 2. Concepts

https://html.spec.whatwg.org/multipage/comms.html#dom-messageevent-source Referenced in:

- 3.1. The portal element (2)
- 3.2. The PortalHost interface (2)

https://html.spec.whatwg.org/multipage/webappapis.html#concept-environment-target-browsing-context Referenced in:

- 4.2. Integration with Content Security Policy
- 4.3. Integration with RFC 7034
- 4.4. Integration with Fetch Metadata Request Headers

https://html.spec.whatwg.org/multipage/webappapis.html#task-source Referenced in:

- 2. Concepts (2)

https://html.spec.whatwg.org/multipage/browsers.html#top-level-browsing-context Referenced in:

- 1. Introduction
- 3.1. The portal element (2)
- 3.3. The PortalActivateEvent interface
- 3.4. Miscellaneous extensions

https://html.spec.whatwg.org/multipage/indices.html#event-unload Referenced in:

- 2. Concepts

https://html.spec.whatwg.org/multipage/urls-and-fetching.html#valid-non-empty-url-potentially-surrounded-by-spaces Referenced in:

- 3.1. The portal element

https://infra.spec.whatwg.org/#assert Referenced in:

- 2. Concepts (2) (3) (4)
- 3.1. The portal element (2) (3)

https://infra.spec.whatwg.org/#boolean Referenced in:

- 3.1. The portal element

https://infra.spec.whatwg.org/#html-namespace Referenced in:

- 2. Concepts

https://w3c.github.io/webappsec-referrer-policy/#referrer-policy Referenced in:

- 3.1. The portal element

https://w3c.github.io/ServiceWorker/#serviceworker Referenced in:

- 3.4. Miscellaneous extensions

https://url.spec.whatwg.org/#concept-url-origin Referenced in:

- 3.1. The portal element
- 3.2. The PortalHost interface

https://url.spec.whatwg.org/#concept-url-scheme Referenced in:

- 3.1. The portal element

https://url.spec.whatwg.org/#concept-url Referenced in:

- 3.1. The portal element

https://url.spec.whatwg.org/#concept-url-parser Referenced in:

- 3.1. The portal element
- 3.2. The PortalHost interface

https://heycam.github.io/webidl/#idl-DOMException Referenced in:

- 3.1. The portal element (2) (3) (4) (5)
- 3.2. The PortalHost interface (2)
- 3.3. The PortalActivateEvent interface

https://heycam.github.io/webidl/#idl-DOMString Referenced in:

- 3.1. The portal element (2)
- 3.2. The PortalHost interface
- 3.3. The PortalActivateEvent interface

https://heycam.github.io/webidl/#Exposed Referenced in:

- 3.1. The portal element
- 3.2. The PortalHost interface
- 3.3. The PortalActivateEvent interface

https://heycam.github.io/webidl/#invalidstateerror Referenced in:

- 3.1. The portal element (2) (3) (4)
- 3.2. The PortalHost interface
- 3.3. The PortalActivateEvent interface

https://heycam.github.io/webidl/#NewObject Referenced in:

- 3.1. The portal element

https://heycam.github.io/webidl/#syntaxerror Referenced in:

- 3.1. The portal element
- 3.2. The PortalHost interface

https://heycam.github.io/webidl/#idl-USVString Referenced in:

- 3.1. The portal element

https://heycam.github.io/webidl/#dfn-frozen-array-type Referenced in:

- 3.1. The portal element
- 3.2. The PortalHost interface

https://heycam.github.io/webidl/#idl-object Referenced in:

- 3.1. The portal element (2)
- 3.2. The PortalHost interface

https://heycam.github.io/webidl/#this Referenced in:

- 3.1. The portal element (2) (3) (4)
- 3.2. The PortalHost interface
- 3.3. The PortalActivateEvent interface (2) (3) (4) (5)
- 3.4. Miscellaneous extensions (2)

### Terms defined by reference

- [csp-3] defines the following terms:
  - navigate-to
- [DOM] defines the following terms:
  - Event
  - EventInit
  - EventTarget
  - adopting steps
  - creating an element
  - creating an event
  - dispatch
  - event constructing steps
  - fire an event
  - node document
  - reflect
  - type
- [ECMASCRIPT] defines the following terms:
  - agent
  - promise
- [FETCH] defines the following terms:
  - destination
  - http(s) scheme
  - initiator
  - request
  - request referrer policy
  - request url
  - reserved client
- [HTML] defines the following terms:
  - CEReactions
  - EventHandler
  - HTMLConstructor
  - HTMLElement
  - MessageEvent
  - MessagePort
  - PostMessageOptions
  - StructuredDeserializeWithTransfer
  - StructuredSerializeWithTransfer
  - Window
  - WindowEventHandlers
  - WindowPostMessageOptions
  - WindowProxy
  - active document
  - associated document
  - becomes browsing-context connected
  - becomes browsing-context disconnected
  - body
  - browsing context (for Window)
  - browsing context group
  - browsing-context connected
  - close a browsing context
  - create a new top-level browsing context
  - data
  - discard a browsing context
  - document browsing context
  - event handler content attribute
  - event handler idl attribute
  - event loop
  - frameset
  - iframe
  - in parallel
  - limited to only known values
  - navigate
  - nested browsing context
  - origin (for environment settings object)
  - parent browsing context
  - parse a url
  - ports
  - prompt to unload
  - queue a task
  - realm (for global object)
  - referrer policy attribute
  - relevant settings object
  - responsible browsing context
  - resulting url record
  - same origin
  - same origin-domain
  - serialization of an origin
  - session history
  - source
  - target browsing context
  - task source
  - top-level browsing context
  - unload
  - valid non-empty url potentially surrounded by spaces
- [INFRA] defines the following terms:
  - assert
  - boolean
  - html namespace
- [REFERRER-POLICY] defines the following terms:
  - referrer policy
- [service-workers-1] defines the following terms:
  - ServiceWorker
- [URL] defines the following terms:
  - origin
  - scheme
  - url
  - url parser
- [WebIDL] defines the following terms:
  - DOMException
  - DOMString
  - Exposed
  - InvalidStateError
  - NewObject
  - SyntaxError
  - USVString
  - frozen array type
  - object
  - this

## References

### Normative References

[CSP]
  Mike West. Content Security Policy Level 3. 15 October 2018. WD. URL: https://www.w3.org/TR/CSP3/
[DOM]
  Anne van Kesteren. DOM Standard. Living Standard. URL: https://dom.spec.whatwg.org/
[ECMASCRIPT]
  ECMAScript Language Specification. URL: https://tc39.github.io/ecma262/
[FETCH]
  Anne van Kesteren. Fetch Standard. Living Standard. URL: https://fetch.spec.whatwg.org/
[HTML]
  Anne van Kesteren; et al. HTML Standard. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[INFRA]
  Anne van Kesteren; Domenic Denicola. Infra Standard. Living Standard. URL: https://infra.spec.whatwg.org/
[REFERRER-POLICY]
  Jochen Eisinger; Emily Stark. Referrer Policy. 26 January 2017. CR. URL: https://www.w3.org/TR/referrer-policy/
[RFC2119]
  S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[SERVICE-WORKERS-1]
  Alex Russell; et al. Service Workers 1. 2 November 2017. WD. URL: https://www.w3.org/TR/service-workers-1/
[URL]
  Anne van Kesteren. URL Standard. Living Standard. URL: https://url.spec.whatwg.org/
[WebIDL]
  Boris Zbarsky. Web IDL. 15 December 2016. ED. URL: https://heycam.github.io/webidl/

### Informative References

[RFC7034]
  D. Ross; T. Gondrom. HTTP Header Field X-Frame-Options. October 2013. Informational. URL: https://tools.ietf.org/html/rfc7034

## IDL Index

    [Exposed=Window, HTMLConstructor]
    interface HTMLPortalElement : HTMLElement {
        [CEReactions] attribute USVString src;
        [CEReactions] attribute DOMString referrerPolicy;

        [NewObject] Promise<void> activate(optional PortalActivateOptions options);
        void postMessage(any message, DOMString targetOrigin, optional sequence<object> transfer = []);
        void postMessage(any message, optional WindowPostMessageOptions options);

        attribute EventHandler onmessage;
        attribute EventHandler onmessageerror;
    };

    dictionary PortalActivateOptions {
        any data = null;
        sequence<object> transfer = [];
    };

    [Exposed=Window]
    interface PortalHost : EventTarget {
        void postMessage(any message, DOMString targetOrigin, optional sequence<object> transfer = []);
        void postMessage(any message, optional WindowPostMessageOptions options);

        attribute EventHandler onmessage;
        attribute EventHandler onmessageerror;
    };

    [Constructor(DOMString type, optional PortalActivateEventInit eventInitDict), Exposed=Window]
    interface PortalActivateEvent : Event {
        readonly attribute any data;
        HTMLPortalElement adoptPredecessor();
    };

    dictionary PortalActivateEventInit : EventInit {
        any data = null;
    };

    typedef (WindowProxy or MessagePort or ServiceWorker or HTMLPortalElement or PortalHost) MessageEventSource;

    partial interface Window {
        readonly attribute PortalHost? portalHost;
    };

    partial interface mixin WindowEventHandlers {
        attribute EventHandler onportalactivate;
    };

## Issues Index

In the case that structured deserialization throws, it may be useful to do something else to indicate it, rather than simply providing null data. ↵
We need to specify how the session history of each browsing context is affected by activation, and supply non-normative text that explains how these histories are expected to be presented to the user. ↵
It might be convenient to not immediately detach the portal element, but instead to do so in a microtask. This would allow developers to reinsert the `portal` element without losing its browsing context. ↵
We should expand this section further. ↵
`activate(options)` should also respect the CSP navigate-to directive. ↵
#portal-state Referenced in:

- 2. Concepts (2) (3) (4) (5) (6) (7) (8) (9)
- 3.1. The portal element (2)
- 3.2. The PortalHost interface
- 3.4. Miscellaneous extensions

#portal-browsing-context Referenced in:

- 2. Concepts (2) (3)
- 3.1. The portal element (2) (3) (4) (5)
- 3.2. The PortalHost interface
- 3.4. Miscellaneous extensions (2)
- 4.1. Overview
- 4.2. Integration with Content Security Policy (2)
- 4.3. Integration with RFC 7034 (2)
- 4.4. Integration with Fetch Metadata Request Headers (2)

#host-element Referenced in:

- 2. Concepts (2) (3) (4)
- 3.1. The portal element (2)
- 3.2. The PortalHost interface

#host-browsing-context Referenced in:

- 2. Concepts (2)
- 3.2. The PortalHost interface (2)
- 4.2. Integration with Content Security Policy
- 4.3. Integration with RFC 7034 (2)

#portal-task-source Referenced in:

- 2. Concepts (2) (3)
- 3.1. The portal element
- 3.2. The PortalHost interface
- 3.3. The PortalActivateEvent interface

#activate-a-portal-browsing-context Referenced in:

- 2. Concepts (2)
- 3.1. The portal element
- 3.2. The PortalHost interface (2)

#adopt-the-predecessor-browsing-context Referenced in:

- 2. Concepts (2)
- 3.1. The portal element
- 3.3. The PortalActivateEvent interface

#elementdef-portal Referenced in:

- 2. Concepts (2) (3)
- 3.1. The portal element (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14) (15) (16) (17) (18) (19) (20) (21)
- 3.3. The PortalActivateEvent interface

#htmlportalelement-guest-browsing-context Referenced in:

- 2. Concepts
- 3.1. The portal element (2) (3) (4) (5) (6) (7) (8) (9) (10) (11)
- 3.2. The PortalHost interface

#htmlportalelement-just-adopted-flag Referenced in:

- 2. Concepts (2) (3)
- 3.1. The portal element

#element-attrdef-portal-src Referenced in:

- 3.1. The portal element (2) (3) (4) (5)

#element-attrdef-portal-referrerpolicy Referenced in:

- 3.1. The portal element (2)

#htmlportalelement Referenced in:

- 2. Concepts
- 3.1. The portal element
- 3.3. The PortalActivateEvent interface
- 3.4. Miscellaneous extensions

#dom-htmlportalelement-onmessage Referenced in:

- 3.1. The portal element

#dom-htmlportalelement-onmessageerror Referenced in:

- 3.1. The portal element

#dictdef-portalactivateoptions Referenced in:

- 3.1. The portal element

#dom-portalactivateoptions-data Referenced in:

- 3.1. The portal element

#dom-portalactivateoptions-transfer Referenced in:

- 3.1. The portal element

#dom-htmlportalelement-src Referenced in:

- 3.1. The portal element

#dom-htmlportalelement-referrerpolicy Referenced in:

- 3.1. The portal element

#dom-htmlportalelement-activate Referenced in:

- 2. Concepts (2)
- 3.1. The portal element
- 4.2. Integration with Content Security Policy

#dom-htmlportalelement-postmessage Referenced in:

- 3.1. The portal element

#dom-htmlportalelement-postmessage-message-options Referenced in:

- 3.1. The portal element (2)

#htmlportalelement-may-have-a-guest-browsing-context Referenced in:

- 2. Concepts
- 3.1. The portal element (2) (3) (4)

#htmlportalelement-close-a-portal-element Referenced in:

- 3.1. The portal element (2) (3)

#htmlportalelement-set-the-source-url-of-a-portal-element Referenced in:

- 3.1. The portal element (2) (3) (4)

#eventdef-htmlportalelement-message Referenced in:

- 3.2. The PortalHost interface

#eventdef-htmlportalelement-messageerror Referenced in:

- 3.2. The PortalHost interface

#portal-host-object Referenced in:

- 3.1. The portal element
- 3.2. The PortalHost interface
- 3.4. Miscellaneous extensions

#portalhost Referenced in:

- 2. Concepts
- 3.2. The PortalHost interface (2)
- 3.4. Miscellaneous extensions (2) (3)

#dom-portalhost-postmessage Referenced in:

- 3.2. The PortalHost interface

#dom-portalhost-postmessage-message-options Referenced in:

- 3.2. The PortalHost interface (2)

#eventdef-portalhost-message Referenced in:

- 3.1. The portal element

#eventdef-portalhost-messageerror Referenced in:

- 3.1. The portal element

#portalactivateevent Referenced in:

- 2. Concepts
- 3.3. The PortalActivateEvent interface (2)
- 3.4. Miscellaneous extensions

#dom-portalactivateevent-data Referenced in:

- 2. Concepts

#dictdef-portalactivateeventinit Referenced in:

- 3.3. The PortalActivateEvent interface

#portalactivateevent-predecessor-browsing-context Referenced in:

- 2. Concepts
- 3.3. The PortalActivateEvent interface (2)

#portalactivateevent-successor-window Referenced in:

- 2. Concepts
- 3.3. The PortalActivateEvent interface (2)

#portalactivateevent-activation-promise Referenced in:

- 2. Concepts (2)
- 3.3. The PortalActivateEvent interface

#portalactivateevent-adopted-predecessor-element Referenced in:

- 2. Concepts
- 3.3. The PortalActivateEvent interface (2) (3)

#dom-portalactivateevent-adoptpredecessor Referenced in:

- 2. Concepts (2)
- 3.3. The PortalActivateEvent interface

#typedefdef-messageeventsource Referenced in:

- 3.4. Miscellaneous extensions

#dom-windoweventhandlers-onportalactivate Referenced in:

- 3.4. Miscellaneous extensions

#dom-window-portalhost Referenced in:

- 3.2. The PortalHost interface
- 3.4. Miscellaneous extensions

#eventdef-window-portalactivate Referenced in:

- 2. Concepts (2)
- 3.1. The portal element
- 3.3. The PortalActivateEvent interface