`IntersectionObserver` observes boxless `display:contents` wrapper, breaking visibility detection for dynamic outputs

[gadenbuie]

Summary

Since #4388 (shiny 1.14.0), a dynamically-rendered output (e.g. uiOutput()) that lives inside a display:contents wrapper is never reported as visible when it becomes visible, so the server keeps it suspended and it renders nothing (it stays stuck recalculating). This surfaces most visibly with bslib popover()/tooltip() content — see downstream report rstudio/bslib#1326.

Reproducible example

library(shiny)
library(bslib)

ui <- page_fillable(
  class = "p-5",
  popover(
    icon("maximize"),
    uiOutput("ui")          # no `title =` on the popover
  )
)

server <- function(input, output) {
  output$ui <- renderUI(span("Hello from the popover!"))
}

shinyApp(ui, server)

Open the popover: the body is empty. Add a title to the popover (or give the output an intrinsic width, e.g. uiOutput("ui", style = "min-width: 1px")) and it renders. Works in shiny 1.13.0; broken in 1.14.0. git bisect points at #4388.

Root cause

PR #4388 changed ensureObservers() so that, for a .shiny-html-output, the IntersectionObserver observes a box-model ancestor (via resolveObservableTarget()) instead of the output itself — because an output with children gets display:contents from the :has(> *) CSS rule, and a boxless element has a permanent intersection ratio of 0.

But resolveObservableTarget() only walks past ancestors that are themselves .shiny-html-output:

shiny/srcts/src/shiny/index.ts

Lines 468 to 484 in 107747a

	function resolveObservableTarget(el: Element): Element {
	if (!el.classList.contains("shiny-html-output")) {
	return el;
	}
	let candidate = el.parentElement;
	while (candidate) {
	if (!candidate.classList.contains("shiny-html-output")) {
	return candidate;
	}
	if (candidate === document.documentElement) {
	break;
	}
	candidate = candidate.parentElement;
	}
	return el;
	}

When the output's parent is some other display:contents element — e.g. bslib wraps popover/tooltip content in <div style="display:contents"> — the walk stops on that wrapper and observes it. That wrapper is also boxless, so the IntersectionObserver still never fires, and visibility changes are never detected. (isVisible() itself is correct; the problem is purely that nothing triggers the refresh.)

Why it looks "title-dependent" downstream

The output's ResizeObserver (still attached to the output element) is the only remaining trigger. It only fires if the output's box size changes from the initial 0×0 it had while hidden. A bslib popover with a title gets intrinsic width from its header, so the empty output gets a non-zero width and the RO fires (masking the bug); without a title the popover collapses to ~0 width, the output stays 0×0, the RO never fires, and nothing renders. So the title axis is a side effect — the real defect is the disabled IntersectionObserver.

Proposed fix

Generalize resolveObservableTarget() to keep walking past any boxless display:contents element, not just .shiny-html-output, so the IO lands on an ancestor that actually has a box (for the popover case, .popover-body). The function's own comment already anticipates this ("if other containers adopt display:contents, generalize here").

Open question for implementation: detect via computed display === "contents" (catches the inline-style case like bslib's wrapper at setup time; note the deferred :has() case is why the original class-name check exists), and/or broaden the structural walk.

[gadenbuie]

RFC: dynamic outputs fail to render when shown inside a relocated/display:contents container

Regression caused by #4388. Draft for discussion (manifests as rstudio/bslib#1326).

Summary

Since shiny 1.14.0 (#4388), a dynamically-rendered output (e.g. uiOutput() / htmlOutput()) can get stuck permanently recalculating — never rendering — when it is bound while hidden and later shown by being moved elsewhere in the DOM. The clearest reproduction is a bslib::popover() / tooltip() with no title containing a uiOutput(): with a title it renders, without one it stays empty.

We've root-caused it and want maintainer input on which of three fixes to take, because the obvious one (generalizing the new resolveObservableTarget() walk) is necessary but not sufficient — we verified it does not fix the case on its own.

Reproduction

library(shiny)
library(bslib)
ui <- page_fillable(
  popover(icon("gear"), uiOutput("ui"))   # no `title=` → bug; add a title → works
)
server <- function(input, output) {
  output$ui <- renderUI(span("Hello from the popover!"))
}
shinyApp(ui, server)

Background: what #4388 changed

#4388 reworked observer setup in srcts/src/shiny/index.ts so that, for a .shiny-html-output element, the IntersectionObserver observes a box-model ancestor instead of the output itself. Rationale: a .shiny-html-output acquires display:contents via a :has(> *) rule once it has children, and a boxless element has a permanent intersectionRatio of 0, so the IO would never fire. resolveObservableTarget() walks up to the nearest ancestor that is not itself a .shiny-html-output.

Root cause

Two facts combine to defeat the current observer setup for this pattern:

1. Observer targets are resolved once, at bind time. For a popover, binding happens at page load, while the popover is closed — the output sits inside a display:none container, wrapped in bslib's display:contents div. At that moment resolveObservableTarget() walks up past the display:contents wrapper and lands on the display:none container.
2. The content is relocated on show. bslib moves the live node (it does not clone it) into the Bootstrap tip's .popover-body when the popover opens, and moves it back on close. So the ancestor captured at bind time is left behind, empty and still display:none — the IntersectionObserver target never becomes visible and never fires.

Meanwhile the output's own ResizeObserver (attached to the output element, so it travels with the node) is the only observer in the right place when the popover opens — but ResizeObserver only delivers a callback when the observed content box size changes. A title-less, empty output measures 0×0 both before and after the popover opens (it's empty, and with no title the popover has no intrinsic width, so a display:block child of a display:contents wrapper gets 0 width). No size delta → the RO never fires → refreshOutputInfo() is never called while the popover is open → the stale hidden = true recorded at page load is never corrected → the server keeps the output suspended.

The logic is already correct — this is a missing trigger

isVisible() is perfectly capable of detecting the shown state:

shiny/srcts/src/utils/index.ts

Lines 62 to 70 in 107747a

	function isVisible(el: HTMLElement): boolean {
	if (el.offsetWidth !== 0 || el.offsetHeight !== 0) {
	return true;
	}
	if (getStyle(el, "display") === "none") {
	return false;
	}
	return el.parentElement ? isVisible(el.parentElement) : true;
	}

In the open popover it climbs from the 0×0 output, past the display:contents wrapper, to .popover-body (non-zero box) and returns true. So if refreshOutputInfo()/doSendHiddenState() ran while the popover were open, the output would render. Every candidate fix below is really about manufacturing that call at show time.

Why the title matters (for the record)

With a title, the popover-header gives the tip an intrinsic width, so the empty output gets a non-zero offsetWidth when shown → a size delta → the ResizeObserver fires → it renders. Without a title there is no width change, so nothing fires.

Note: this is not bslib-specific

#4388 is a general behavior change. Any container that binds an output while hidden and reveals it by relocating the node (or otherwise without changing the output's own box size) can hit this. We'd like a fix that does not require downstream changes in bslib or other packages.

The "obvious" fix is insufficient (verified)

The natural first move is to generalize resolveObservableTarget() to also skip any ancestor whose computed display === "contents" (not only .shiny-html-output), so the IO lands on a real box like .popover-body:

const isBoxless =
  candidate.classList.contains("shiny-html-output") ||
  getComputedStyle(candidate).display === "contents";

We implemented and browser-tested this. It does not fix the bug on its own, because resolution still happens at bind time (popover closed) — the walk now skips the display:contents wrapper but lands on the display:none container, and the content is relocated on open regardless. It remains a reasonable correctness improvement for inline display:contents wrappers that are visible at bind time, but it does not address the relocation/one-shot-resolution problem.

Options

Option A — global min-width: 1px on .shiny-html-output

Add a single rule to shiny's stylesheet so every html output has a 1px minimum width.

• Pro: smallest possible change; reuses the already-correct ResizeObserver + isVisible() path; fixes the regression for all containers, not just bslib; no runtime cost. Once an output has content it's display:contents, so the rule is a no-op (no visual impact). min-width alone is sufficient (the RO fires on any single-dimension change; the IO would need non-zero area).
• Con: a 1px minimum applies to every html output globally (negligible but universal); it's an implicit, CSS-driven trigger rather than an explicit event; it works around — rather than removes — the one-shot bind-time resolution.

Option B — document-wide MutationObserver + output registry

Watch the document for relocations and call refreshOutputInfo() when a registered output is (re)inserted.

• Pro: event-driven; no CSS footprint; isVisible() already returns the right answer at that point.
• Con: a new always-on global observer wakes its callback on every DOM mutation (a registry/WeakSet speeds the reject path but doesn't reduce wake frequency); the relocation case moves the wrapper, so the callback must scan the inserted subtree for outputs rather than do an O(1) lookup; re-entrancy/debounce care needed. More machinery and perf surface than A for the same outcome. (shiny has no existing global bind-observer to piggyback on — bindAll is invoked explicitly on render/insert, so a pure relocation triggers no shiny code today.)

Option C — make the output an autonomous custom element <shiny-html-output>

Give the output container custom-element lifecycle callbacks and re-resolve observers + call refreshOutputInfo() in connectedCallback.

• Pro: connectedCallback is the native "I was (re)connected to the DOM" hook — the browser dispatches it only to elements that actually (re)connected (including custom-element descendants of a moved subtree), so no global scanning. This is the only option that directly resolves the root cause. Every other approach works around the one-shot, bind-time resolution by manufacturing a trigger; this one removes the faulty assumption itself — observers are (re)resolved against the live DOM on every connect instead of once while hidden, which also makes the IntersectionObserver path correct for relocations. It is the principled fix.
• Con / open question: the one genuinely significant concern is that this changes the literal tag emitted by uiOutput()/htmlOutput()/tableOutput(). We can't use the low-risk customized built-in form (<div is="shiny-html-output">), which would keep the <div> as-is, because is= is not supported in Safari/WebKit — so an autonomous <shiny-html-output> is required. The .shiny-html-output class (public, CSS-referenced) stays, so class selectors and output bindings keep working, but anything assuming the <div> tag could break; that migration is the real question to weigh. The autonomous element's display:inline default is a trivial fix (one baseline display:block rule, plus the inline=TRUE span variant), and connectedCallback hygiene (guard isConnected, debounce, ignore the disconnect half of a move) is minor.

Recommendation / questions for discussion

• For unblocking the regression now, Option A is the lowest-risk, downstream-free change. (bslib has already shipped the equivalent min-width scoped to popovers/tooltips as a temporary workaround; a shiny-side global rule would generalize it and let bslib drop the workaround.)
• Option C is the only option that directly resolves the root cause, and is the correct long-term model. Its one real cost is the tag migration (Safari's lack of is= forces an autonomous element, so the emitted tag changes) — a deliberate refactor rather than a quick regression patch, but the principled endpoint.

Questions:

1. Are we comfortable shipping Option A as the immediate fix?
2. Is there appetite for Option C (<shiny-html-output>) as a follow-up, or concerns about the autonomous-element migration that would rule it out?
3. Is the resolveObservableTarget() display:contents generalization worth keeping on its own merits (independent of this bug)?

[gadenbuie]

Follow-up on Option C: the visibility bug is actually the smallest payoff. Switching html outputs to an autonomous custom element (<shiny-html-output>) would unlock lifecycle guarantees that the current explicit-bindAll/unbindAll model structurally can't provide. (There's already in-repo precedent — shiny defines shiny-error-console and shiny-error-message via customElements.define today.)

The big ones — lifecycle the platform guarantees

1. Reliable teardown on removal (fixes a real leak class). Observers (ResizeObserver, IntersectionObserver, the theme MutationObserver) and bindings are torn down today only when shiny removes the UI through its own unbindAll path (srcts/src/shiny/render.ts). If anything else removes the node — a third-party widget, bslib, user JS, a JS framework — shiny never unbinds: leaked observers, leaked handlers, and stale entries in internal registries (e.g. the visibleOutputs set, the binding map). disconnectedCallback is a guaranteed teardown hook no matter who removes the node. This is arguably a bigger correctness win than the popover bug itself.

2. Self-binding on insertion (no more "remember to call Shiny.bindAll"). Symmetrically, outputs get bound today only when shiny knows it inserted them. Content injected by arbitrary JS that forgets Shiny.bindAll() silently stays dead. connectedCallback lets the element register/bind itself whenever it enters the DOM, so dynamic insertion "just works." (Caveat: it must queue when Shiny isn't initialized yet.)

3. Generalizes the visibility fix to every reveal/relocate path. The popover is one instance of a recurring family: outputs that don't recalc when revealed in tabsetPanel, accordion/collapse, conditionalPanel, modals, offcanvas, or drag-and-drop layouts. Connected/disconnected plus re-resolving observers against the live DOM addresses all of those uniformly, rather than one workaround per container.

Secondary architectural wins

4. Observer lifecycle owned by the element. Move ensureObservers into connectedCallback and teardown into disconnectedCallback. That retires the global $(".shiny-bound-output").each(...) scan in doSendOutputInfo and the bag of jQuery .data() state, scoping each observer to the element's actual lifetime.

5. adoptedCallback for cross-document/iframe moves. shiny has bespoke iframe handling hanging off bindAll; adoptedCallback fires precisely when a node moves between documents, giving a clean centralized hook.

6. attributeChangedCallback for declarative state (minor). State like recalculating/aria-busy/fill-sizing could be reacted to on the element rather than pushed in from outside. Marginal, but tidy.

7. A real object model — alignment, testability, interop. The output becomes a first-class element with methods instead of a <div> plus external machinery. It matches the direction bslib already took (everything is a web component), making shiny↔bslib coordination cleaner, and an element class is far easier to unit-test than the current distributed state.

Two honest caveats so this doesn't oversell

• We would not use shadow DOM — and shouldn't. Output content must be styled by page/theme CSS and stay query-selectable by user and third-party code; shadow encapsulation would break exactly that. So the usual "style encapsulation" selling point of custom elements is a non-goal here (and would be a regression).
• DOM-driven bind/unbind changes semantics and needs care. A node briefly detached then reattached (some layout libs do this) fires disconnect→connect, so you need debouncing, an isConnected guard, idempotent bind, and a deliberate decision about whether transient detachment preserves or resets output state. The wins in point 1 and point 2 are real, but not free.

Net: the visibility bug is the smallest payoff here. The genuine prize is lifecycle correctness — guaranteed teardown and insertion-agnostic binding — which would close a recurring class of leak / "stale output" bugs that the current explicit-bindAll/unbindAll model can't structurally cover.

[cpsievert]

Thanks for investigating and writing this up.

Are we comfortable shipping Option A as the immediate fix?

Yes, this seems like a very reasonable and clever workaround. Are you thinking we would do it just for bslib tooltips or apply it more generally to .shiny-html-output?

Is there appetite for Option C () as a follow-up, or concerns about the autonomous-element migration that would rule it out?

Yea, it's definitely worth some investigation! I would mainly be worried about scope creep, but it also feels indefensible to not be moving in this direction long term.

Is the resolveObservableTarget() display:contents generalization worth keeping on its own merits (independent of this bug)?

I think I'd be okay punting on it (unless we have real and problematic scenarios) and instead focus on option C.

[gadenbuie]

Are we comfortable shipping Option A as the immediate fix?

Yes, this seems like a very reasonable and clever workaround. Are you thinking we would do it just for bslib tooltips or apply it more generally to .shiny-html-output?

I guess at this point I'm thinking that rstudio/bslib#1327 covers the immediate fix option. I think it's worth broadly fixing the issue via Option C in the long run, but the circumstances of how tooltips/popovers introduce this issue are likely quite uncommon because it combines both placing UI elements in a display: contents container AND moving the elements in the DOM to reveal them.