FB24198765 - Safari extension popup auto-resize causes broken scroll, dark-mode & vibrancy bugs

[rxliuli]

Originally filed with Apple as FB24198765, mirroring here per the convention in this repo since Feedback Assistant reports aren't publicly searchable.

Summary

A Safari Web Extension's popup window auto-resizes its native container to match the popup document's content height as that content changes (e.g. navigating between views, async data loading in). This auto-resizing behavior itself appears to be the root cause of at least four distinct, previously-unconnected-looking rendering bugs in the popup:

1. No elastic/momentum scroll physics on any overflow: auto/overflow: scroll element inside the popup — scrolling feels "dead", with none of the rubber-band bounce or inertia normally present in WebKit.
2. prefers-color-scheme sometimes not detected — the popup renders in light mode even though the OS/browser is in dark mode, while the web page in the tab behind the popup correctly renders dark. This is intermittent, not always reproducible.
3. Native vibrancy/blur-behind material bleeding through the popup — the blurred content of the tab behind the popup is briefly visible through the popup's own content immediately after it opens, even though DOM inspection confirms the popup's own elements are already correctly rendered underneath.
4. Scroll position not resetting between in-popup navigations — when the popup uses client-side routing (no full page reload) to switch between views, and the new view is shorter than the previous scroll position, the browser does not reset scroll to the top; scrollRestoration: true equivalents in JS routers do not fix this either.

imp-rec-2026-08-07-105253.mp4

imp-rec-2026-08-07-110547.mp4

Environment

• Safari 26.6, macOS 26.6 (Tahoe)
• Safari Web Extension (built with WXT, Manifest V3, React popup)

Steps to reproduce

1. Build a Safari Web Extension with a popup whose content height changes after the popup opens (e.g. an async data fetch that replaces a loading state with a longer list, or client-side navigation between views of different heights).
2. Open the popup, and:
   • Scroll a tall list inside it — note the lack of elastic/rubber-band scroll physics.
   • Toggle the OS or Safari appearance between light/dark and reopen the popup a few times — note that prefers-color-scheme is sometimes not picked up.
   • Watch the moment the popup opens over a scrolled, visually busy tab — note the tab's blurred content briefly showing through.
   • Add client-side navigation to a route with a scroll position, then navigate to a shorter route — note the scroll position is retained instead of resetting.

Root cause / what fixed it

All four symptoms disappeared simultaneously once the popup was changed to never let its native window resize after first paint — i.e. pinning html/body to one fixed width/height up front (before first React render), and having body itself scroll (overflow-y: auto) rather than relying on the window growing/shrinking to fit nested scroll containers.

/* Safari only */
html.safari-fixed-popup,
html.safari-fixed-popup body {
  width: 672px;
  height: 600px;
  overflow-x: hidden;
  overflow-y: auto;
}

if (import.meta.env.SAFARI) {
  document.documentElement.classList.add('safari-fixed-popup')
}

This strongly suggests the popup's native resize-to-content mechanism interacts badly with WebKit's own scroll-physics setup, compositing/vibrancy layer, and prefers-color-scheme media query evaluation — each of those appears to only be (re-)initialized correctly when the window's final size is stable at first paint, not when it changes afterward.

Related but distinct reports

• bugs.webkit.org #296056 — "iPadOS 26: Safari extension popup windows open scrolled down", RESOLVED FIXED. Different root cause (focus-restoration scroll after a <dialog> closes), but same general category of "popup scroll state gets corrupted by WebKit-internal behavior".
• Apple Developer Forums #698319 — reports that on iPad the popup's native container grows to fit taller content but fails to shrink back down again, i.e. direct evidence that the resize-to-content mechanism itself is unreliable.
• Apple Developer Forums #675652 — prefers-color-scheme always false in a popup, unanswered since 2021.

Workaround

Pin the popup's html/body to a fixed size before first paint (Safari only — Chrome and Firefox are unaffected) and scroll body directly instead of nesting overflow: auto containers sized to the (previously) dynamically-resizing window.

[carlosjeurissen]

@rxliuli great summary of some of the issues of web extension action popups. It is one of the driving forces behind my proposal at:
w3c/webextensions#692

Recently raised an issue on the scrolling related issues:
https://bugs.webkit.org/show_bug.cgi?id=320810
This also probably explains the scrolling restoration. When the popup is in this weird scrolling mode, window.scrollTo() also fails.

As for iPadOS action popups not shrinking. I was unable to reproduce this issue. Checked some extensions I developed and on iPadOS they all shrink back down. Potentially this has since been resolved?

The blur-behind material I believe is a stylistic choice by Safari. You can opt-in to this by setting your background to (semi)transparent.

As for prefers-color-scheme, this requires the <meta name="color-scheme" content="light dark"> meta tag. If you add this the media query should work as expected.