Other charts are overlapping with Table chart when downloading dashboard as image using "Download as Image" option #40428

Activity

1. dosubot

   added

   browser:chromeRelated to the Chrome browserRelated to the Chrome browser

   dashboard:exportRelated to exporting dashboardsRelated to exporting dashboards

   viz:charts:tableRelated to the Table chartRelated to the Table chart

   on May 26, 2026
2. dosubot commented on May 26, 2026

   

   dosubotBot

   on May 26, 2026 – with DosuBot

   More actions

   This is a known area that has received multiple fixes. The overlapping behavior during "Download as Image" has been traced to two root causes:

   1. CSS box-sizing issue — .dashboard-component-chart-holder elements default to content-box instead of border-box, causing their 32px padding to overflow the container and overlap neighboring charts. PRs #36375 and #38536 address this [1].

   2. Scrollable Table content expanding during export — PR #34233 rewrote the image export utility to set overflow: visible and height: auto on scrollable containers so full table content is captured. However, this expansion can cause the Table chart's exported height to exceed its dashboard grid slot, pushing into or overlapping adjacent charts [2].

   Additionally, PR #38781 (merged April 2026) specifically targets ag-grid table rendering in image exports — it switches to print layout during capture and preserves row/column dimensions to prevent overlapping [3].

   Immediate workaround: You can add this CSS override to your dashboard to fix the box-sizing issue:

   .dashboard-component-chart-holder {
       box-sizing: border-box;
   }

   If you're on version 6.0.0, you may not have the latest export fixes from PRs #34233, #38781, or #38536. Upgrading to a more recent build that includes these patches should resolve the overlapping behavior during image download.

   To reply, just mention @dosu.

   ---

   Docs are dead. Just use Dosu.

   
3. rusackas commented on Jun 1, 2026

   

   rusackas

   on Jun 1, 2026

   Member

   More actions

   Can you validate if this is also happening in 6.1?
4. RehanIslam09 commented on Jul 13, 2026

   

   RehanIslam09

   on Jul 13, 2026

   Contributor

   More actions

   Can you validate if this is also happening in 6.1?

   I tested this on the current master branch (6.1 development build) and can still reproduce the issue.

   The dashboard renders correctly in the browser, but after using Download as Image, the Table chart content overflows its container and is rendered underneath adjacent charts (Pie chart, Treemap, etc.), causing visual overlap.

   I tested using the Video Game Sales example dashboard with the Table chart positioned first and containing scrollable content

   

   Additional observation: I was not able to reproduce the issue when exporting the same dashboard as a PDF. The PDF export preserved the expected layout, and the overlap only occurred with Download as Image.

   Dashboard

   

   Exported as PDF ss :

   
5. RehanIslam09 commented on Jul 13, 2026

   

   RehanIslam09

   on Jul 13, 2026

   Contributor

   More actions

   Hi,

   I've been investigating this issue locally and wanted to share my findings to help move this toward a resolution.

   I traced the root cause of the visual overlap directly to the processCloneForVisibility() function located in superset-frontend/src/utils/downloadAsImage.tsx.

   The Core Conflict

   Through isolated testing, I discovered that the overlap issue disappears entirely if I remove the broad [style*="overflow"] selector from scrollableSelectors.

   However, simply removing or omitting this selector immediately reintroduces the regression that was originally resolved in PR #34233 ("ensure full table or handlebar chart is captured in image export"). When it is removed, table charts revert to exporting only the visible viewport rows rather than the entire dataset.

   Technical Approaches Evaluated

   To find a middle ground, I attempted several targeted adjustments to narrow the scope of the selector without breaking the fix from #34233. Unfortunately, none of these approaches successfully preserved both behaviors simultaneously:

   • Scoped Class Targeting: Restricting the selector explicitly to .superset-chart-table or targeting only role="presentation" containers caused the table export to revert to copying only visible rows.
   • Dynamic Style Evaluation: Swapping the string-based inline style match for an explicit getComputedStyle() check did not resolve the overlap behavior.
   • Lifecycle and Timing Adjustments: Introducing a slight delay to allow for additional layout reflows prior to executing domToImage.toJpeg() yielded no change.
   • Regression History Analysis: I audited the implementation against the original fix(chart-download): ensure full table or handlebar chart is captured in image export #34233 commit and subsequent PRs (such as fix(frontend): resolve image download formatting and cleanup issues #38927) to check for introduced side effects, but could not isolate a specific divergence.

   Key Observations

   1. Export Path Specificity: The overlap reproduces exclusively on the standard clone-based export pipeline (createEnhancedClone() / processCloneForVisibility()). The AG Grid export pipeline remains unaffected.
   2. Container Mechanics: While the actual scroll container for the table appears to be a role="presentation" element with overflow: auto, the full-table export relies on expanding multiple parent or ancestor elements matching the broad overflow criteria, rather than just the immediate scroll container itself.

   Because the full-table export and the visual overlap appear to be tightly coupled within the current architecture, resolving this cleanly will likely require a more nuanced approach than just modifying the selector query.

   Request for Context

   To help guide a proper fix, could anyone provide additional context on why PR #34233 intentionally targeted every element matching [style*="overflow"]?

   I am curious if there was a specific deeply-nested DOM architecture or a particular browser-specific limitation that mandated such a broad dragnet at the time. Understanding that underlying constraint will be incredibly helpful in figuring out how to fix #40428 without regressing #34233.

   Thanks in advance for any insights!
6. rusackas commented on Aug 7, 2026

   

   rusackas

   on Aug 7, 2026

   Member

   More actions

   @RehanIslam09 dug into this a bit. Each chart holder's height in ResizableContainer is a fixed px value off the stored layout (heightStep * heightMultiple), not fit-content, so overflow: visible on the table paints outside that box without growing it or the row. That's why it overlaps instead of reflowing. A real fix probably means resizing the container to the table's expanded scrollHeight inside the clone, not just toggling overflow on the inner elements.
7. RehanIslam09 commented on Aug 11, 2026

   

   RehanIslam09

   on Aug 11, 2026

   Contributor

   More actions

   Thanks a lot for digging into this, that clarifies the behavior a lot.

   That does make a lot of sense, since the chart holder height is fixed from the dashboard layout, switching to overflow: visible only affects painting, not layout, so the table expands visually but the container (and row) doesn’t reflow.

   Based on this, I’m thinking the fix needs to happen at the clone stage by explicitly syncing the container height with the table’s expanded content. Something along the lines of:

   • Measure the table’s scrollHeight after applying the overflow adjustments
   • Propagate that height up to the corresponding .dashboard-component-chart-holder (and possibly its parent row containers) inside the cloned DOM
   • Ensure the layout reflows before calling domToImage

   This would preserve the full-table export behavior from #34233 while preventing overlap by actually resizing the layout instead of just allowing overflow.

   I’ll try prototyping this approach inside processCloneForVisibility() / createEnhancedClone() and see if I can get a stable result without breaking other chart types.

   Let me know if this direction aligns with what you had in mind or if there are constraints I should be aware of while working on this
8. rusackas commented on Sep 5, 2026

   

   rusackas

   on Sep 5, 2026

   Member

   More actions

   That's the right direction - sync the cloned chart holder's height to the table's expanded scrollHeight before domToImage, not just toggling overflow. Go for it.
9. sadpandajoe

   added

   🦾 ai-candidate

   on Sep 17, 2026
10. sadpandajoe

    added a commit that references this issue on Sep 18, 2026

    fix(dashboard): stop table charts bleeding over neighbours in image e…

    ...

    This issue will close once commit 9715057 is merged into the 'master' branch.

    9715057
11. sadpandajoe

    closed this as completedin #44414on Sep 21, 2026