Purpose-Built Templates

ZU2B Blueprints

Business in a Box

  • Purpose-built launch kits for local service businesses — website, copy, prompts, SEO, and more.
  • Local Launch Kits →

Website Widgets

  • Working features you install once and own outright — no plugin, no subscription.
  • Chat Widget — Coming Soon

Reference

ZU2B Pulse™

See what visitors experience before they leave — paste any public URL and get a plain-English performance report in seconds.

Scan Your URL Free
,

Why a “Floating” Button or Widget Sometimes Doesn’t Float

Field Note #148
🔬 Generalized 🔴 Advanced ⏱ 30 Minutes ✓ Observation from Experience
You have a chat bubble, a “back to top” button, or some other element that’s supposed to stay fixed in one corner of the screen no matter how far a visitor scrolls. On most pages, it works exactly as expected. On one specific page — often one built with a page builder or a “custom code” block — it either scrolls away with the content, sits at the wrong spot, or its pop-up gets sliced off entirely when opened.
This one has two distinct possible causes, and they call for two completely different responses.

What’s actually happening
An element styled with position: fixed is designed to anchor to the actual browser window, staying put regardless of scrolling — that’s the whole point of using it for a floating widget. But this only holds true if none of its parent elements have certain CSS properties applied, most commonly transform (also filter or perspective). If any ancestor — even one several levels up — has one of these, the fixed element stops anchoring to the true browser window and instead anchors to that ancestor. Page builders often apply a transform to sections invisibly, as part of their own drag-and-drop or resize-handle functionality, with no obvious sign in the visual editor that it’s happening.
A second, unrelated cause produces a similar-looking symptom: some page builders render their “custom code” blocks inside a hidden <iframe>, as a security measure to isolate arbitrary code from the rest of the page. A fixed-position element can never visually escape an iframe’s boundary — this is an intentional browser security limit, not a bug, and no CSS or JavaScript trick from inside the iframe can override it.

How to tell the difference
Scroll the affected page. If the element moves along with the content instead of staying perfectly still, you’re almost certainly looking at the transform-ancestor cause. If the element’s launcher stays put correctly but its pop-up gets clipped or cut off at a fixed height no matter what you do, that points toward the iframe cause instead.

The fix
For the transform-ancestor cause: a developer can have the widget’s own script relocate it to be a direct child of the page’s <body> tag the moment it loads, which escapes whatever transformed container it started inside, regardless of how deep it was nested.
For the iframe cause, there is no code-level fix — nothing running inside an iframe can make an element visually break out of it. The practical workaround is to stop relying on the floating widget on that specific page, and instead place a plain link or button that sends visitors to a different, non-sandboxed page where the same widget already works correctly.

How to avoid it next time
Don’t assume a floating widget will behave identically on every platform or page builder just because it works on your main site. Page builders can introduce invisible wrapper behavior — a transform here, a sandboxing iframe there — that isn’t mentioned anywhere in their documentation. Test the actual, published result on each specific platform before considering it done.

Tagged in :

,

More from the field