Preset Feature Feedback
What is the problem or goal you're trying to solve or accomplish?
Customers embedding Preset dashboards in their own applications want end users to be able to apply filters without hunting for the Apply button. Today the vertical filter bar positions its Apply filters / Clear all buttons at the bottom of a container sized to viewport height. That works when the viewport is the browser window, but in an embedded context the host application controls iframe height, and any iframe taller than the window relocates the buttons to the bottom of the full document — potentially thousands of pixels below the fold.
Customer's users (external partners on their Partner Portal) must scroll several viewport heights to apply a filter, and in the customer's words this is in some cases impossible. Because filtering is the primary interaction on their embedded reports, this affects every report they embed.
Measured on a 746px-tall browser window: with the iframe bounded to the window the buttons stay visible with no page scroll; with a static 4,000px iframe the same buttons sit 3,356px down the document.
The desired outcome: the filter bar's action buttons remain visible and reachable regardless of how the host sizes the iframe, so embedding customers are not required to constrain iframe height or change their filter bar orientation to get working filters.
Relationship to [BUG-TICKET-REF] (https://preset.atlassian.net/browse/PPR-1404), and why this request is not resolved by it. That ticket covers a separate defect: getScrollSize() reports a content height that depends on iframe height, so hosts sizing the iframe from that value grow it without bound. Fixing it stops the button from continuously receding, which is a real improvement. It does not bring the button into reach. A host that sizes the iframe to a stable content height taller than the browser window — the normal, intended use of that API — still ends up with the buttons at the bottom of a document taller than the screen. This request covers that remaining gap and can outlive the resolution of that ticket.
The scope is not customer-specific. Any embedding customer whose iframe is taller than the browser window, on any dashboard using a vertical filter bar, will hit this — and sizing the iframe taller than the window is the entire point of content-fit sizing, which is the approach our own embedding documentation recommends. The available workarounds each remove a capability the customer is paying for: bounding the iframe height reintroduces a nested scrollbar and breaks the seamless single-page experience that embedded analytics is bought for, while switching to a horizontal filter bar imposes a visible layout change on the customer's own end users. The only configuration that keeps content-fit sizing and brings the buttons back into reach relies on unsupported CSS overrides targeting internal DOM structure by positional selector — and even that is partial: in testing it left the height still growing and broke the same dashboard's standard non-embedded view entirely. That is not a durable solution on a managed platform where upgrades arrive on our schedule, not the customer's. That is the gap this request addresses.
How are you solving it currently?
The customer is implementing one of two Support-provided workarounds, both of which they have explicitly stated have consequences they don't love:
Bounding the iframe height rather than fitting it to dashboard content. Works, but the customer perceives this as giving up dynamic sizing, and it introduces a nested scrollbar.
Switching affected dashboards to a horizontal filter bar. Works, but imposes a layout change on end users accustomed to the existing filter placement.
In the customer's words: "We are relying on Preset to provide a stable dashboarding experience for our customers where we don't have to rely on workarounds."
Neither workaround is documented. The embedding documentation currently recommends content-fit sizing with no guidance about this interaction, so customers reach a working configuration only via Support.
What is your recommended solution?
Customer's stated expectation, verbatim: "The Apply button should remain in a fixed position within the filter panel (or at the bottom of the filter modal), allowing the user to easily apply the selected filters."
The customer has not proposed an implementation. Support suggestions for engineering to evaluate:
Anchor the vertical filter bar's action buttons to the visible viewport rather than to the container's computed height, so they remain on screen regardless of iframe height.
Alternatively, cap the filter bar container's height at the lesser of window height and iframe height, so it does not stretch with an oversized iframe. This would help both this request and [BUG-TICKET-REF] — though testing shows it is not on its own sufficient for that ticket: with the filter bar collapsed (run 5) and with its container capped via CSS (run 6), the measured height still grew at a constant +40px/poll, indicating at least one other viewport-relative container participates.
Note: this request was raised upstream by an unrelated embedding customer describing the same interaction (apache/superset discussion #35268). It was tagged design:suggest and handled as a design discussion rather than a defect. A Preset-side decision is therefore needed; waiting on upstream is unlikely to resolve it.
