Hover a column header below, then scroll the table sideways and hover one of the later columns. The popup should sit under whichever header you are on. Switch how it is placed with the buttons below — two use CSS anchor positioning, one measures the header in JavaScript — and watch the readout in the corner: ALIGNED means the popup found its header. In a web view without anchor positioning, only the measured mode does. environment reports what this engine actually supports.
In Safari a page placed its dropdowns with CSS anchor positioning, and that works fine, bundled into a desktop app with Electrobun for instance, the same code broke: menus drew on top of the buttons that opened them, and popups for column headers were visible on load, then opened somewhere off-screen for any column you had to scroll right to reach.
The cause is that a desktop shell which doesn't bundle its own Chromium —
Electrobun, Tauri, a SwiftUI wrapper — renders in the system WKWebView, and
that is not the same engine as Safari. Anchor positioning is an experimental WebKit
feature: Safari 26 turns it on, WKWebView leaves it off, and a page cannot turn it
on for itself. With the rules dropped, a position: fixed popover falls
back to its static position — where it happens to sit in the document,
uncorrected for scroll. That is exactly the pattern above: fine until the page is
scrolled, then wrong by however far you scrolled.
Nor is the flag a fix. Forced on through
WKPreferences._setEnabled(_:forFeature:), that WebKit still has no
position-area, and the anchor() it does have resolves to
document coordinates and ignores scroll — the second mode above, and it fails here
too. So the fallback has to be a measured one, which is the third.
"Runs the same in the app" holds only as far as the app's engine matches the browser's. Feature-detect the parts you rely on, and keep a path that works when they are missing.
hover a column header