OverlayHostOptions
The configuration of an OverlayHost: callbacks resolving where the feature UI lives, called on every sync, and optional borrowed collaborators.
Properties
module:ui/overlayhost~OverlayHostOptions#bodyCollectionAn existing body collection to host instead of creating one – used by
EditorUI, whose collection belongs to theEditorUIView. A borrowed collection is not destroyed bydestroy; its owner destroys it.resolveInlineContainer?: () => ( ShadowRoot | HTMLElement | null | undefined )module:ui/overlayhost~OverlayHostOptions#resolveInlineContainerResolves the DOM node holding the feature's inline UI – the parts the feature renders directly into its own container (buttons, badges, and similar), as opposed to the floating views it puts into the
bodyCollection. Usually the container element itself, but it may also be a shadow root, when that root is all the feature knows of the tree its inline UI lives in.The host registers this node with its
shadowRootRegistryso the sharedTooltipManagercan drive the tooltips of that inline UI. This matters when the inline UI sits inside a shadow root: in events observed at the document level the elements inside the root are hidden behind their shadow host, so the tooltip manager has to attach its listeners inside each registered root – without this node being registered, the tooltips of the feature's inline UI would never fire. The node is re-resolved on everysync, so the registration follows the feature if it moves to a different container.Omit it when the feature has no tooltip-bearing UI outside the body collection, or when those nodes are registered directly with the
shadowRootRegistryinstead.resolveMountTarget: () => ( ShadowRoot | HTMLElement | null )module:ui/overlayhost~OverlayHostOptions#resolveMountTargetResolves the element or shadow root the
bodyCollectionshould be mounted in – that is, where the feature's floating views end up in the DOM. The collection is appended as a top-level child of this target, which should meet two requirements at once:- it adopts the same styles as the root the feature's UI lives in – typically a shadow root sharing that root's adopted stylesheets – so the floating views are styled like the rest of the feature's UI;
- it sits at the end of
document.body, both so thatoverflowon the ancestors between the feature and the document body cannot clip the floating UI, and so that it paints above the rest of the UI (DOM order decides paint order within a stacking context) instead of below it.
A dedicated shadow root appended at the end of
document.bodythat mirrors those styles satisfies both. The target is therefore not required to be the feature's own root, and to stay unclipped and on top it usually should not be nested inside the feature's container.Return
nullto keep the collection unmounted – for example while the feature's container is not connected to the document yet, so there is no root to resolve. The target is re-resolved on everysync, so the collection is re-mounted if the feature moves to a different root and unmounted once its container goes away.getOverlayMountRootcovers the common resolution from an anchor node (the feature's container): the anchor's shadow root when it lives in one,document.bodyin the light DOM, ornullwhile the anchor is detached.module:ui/overlayhost~OverlayHostOptions#shadowRootRegistrymodule:ui/overlayhost~OverlayHostOptions#tooltipManagerA borrowed reference to the shared tooltip manager to register the body collection with, instead of the host acquiring (and on destroy releasing) a reference of its own – used by
EditorUI, so an editor keeps counting as a single holder of the singleton. The holder of the borrowed reference releases it.module:ui/overlayhost~OverlayHostOptions#updateEmitter