Repository navigation
Upon download as PDF, charts on a long dashboard render as loading image #29719
Description
Bug description
My user has a long dashboard - 41 charts on the tab she is downloading to PDF. I wait for the charts to all load. Then when I click Download -> PDF, the first 7 charts (Firefox) or 9 charts (Chrome) are rendered, followed by the remaining ~32 charts that have the loading symbol.
If I use my browser (both Chrome and Firefox) print function, the first 9 charts are rendered, followed by 32 with loading symbols. Possible duplicate of #27008 which was closed for lack of details.
How to reproduce the bug
Create a dashboard with very many charts in one tab, each with a moderate load time (say 0.5+ seconds). Let all the charts load. Export to PDF or use the browser print-to-PDF function.
Screenshots/recordings
Superset version
4.0.2
Python version
Not applicable
Node version
Not applicable
Browser
Chrome
Additional context
No response
Checklist
- I have searched Superset docs and Slack and didn't find a solution to my problem.
- I have searched the GitHub issue tracker and didn't find a similar bug report.
- I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.
Activity
sfirke commentedon Jul 26, 2024
A naive question: if all of the charts have loaded in my browser, why would any of them be the loading icon when I print to PDF?
rusackas commentedon Jul 26, 2024
I think this is a duplicate of #29719
I also think @kgabryje might have looked at this while I was away on vacation... but I haven't caught up on the result yet.
sfirke commentedon Jul 26, 2024
@rusackas you linked back to this same issue, did you mean to link to a different one? EDIT: I bet you meant #28713, yes that looks similar
Xyrai commentedon Aug 1, 2024
Same issue here, I want my users to be able to print the graphs on the page that are rendered outside of their viewport.
I am using the
@superset-ui/embedded-sdkNPM package, it would be really nice to have an update within there or an option to toggle this kind of feature. Also, is there a way to check when the rendering of all graphs have finished?nandwalritik commentedon Aug 7, 2024
@sfirke Same Issue occurs when downloading as image, any fix available for above bug?
kgabryje commentedon Aug 7, 2024
I think this might be fixed by #29272 (CC @geido)
Xyrai commentedon Aug 16, 2024
Still seems to be broken on my side sadly while using
superset-ui/embedded-sdk. I tried a workaround where you have to adjust theiframeSandboxExtrasoptions and includeallow-modalsto it. This way you can focus on the iframe via the DOM tree and fire awindow.print()event to only have the dashboard rendering on the browser PDF.However, this still seems to showcase only the graphs that are within the viewport of a user.
In case the version matters, I tried this on the latest one
"@superset-ui/embedded-sdk": "^0.1.0-alpha.12"123srikan commentedon Aug 20, 2024
any update on this issue.
MNITD commentedon Sep 9, 2024
From what my team investigated it might be due to the virtualization feature - i.e. the superset UI off-loads charts that are away from the viewport
So I am not sure there is such thing as "all-charts-were-loaded" event
In our case, we found a workaround:
docker/pythonpath_dev/superset_config_docker.py)FEATURE_FLAGSvariable:Now the dashboard loads charts once without off-loading them during the scroll
In result, we don't have any loading spinners on the downloaded PDF
Perhaps it will help someone 👀
geido commentedon Sep 9, 2024
Thanks, looking into it
zachoooo commentedon Feb 7, 2025
That's really interesting. It sounds like maybe virtualization just needs to be disabled when downloading.
rusackas commentedon May 28, 2025
Assuming this one is still an issue? Just asking since it's been quiet here since February :D Also curious if it's an issue at all when
PLAYWRIGHT_REPORTS_AND_THUMBNAILSis enabled.rusackas commentedon Jun 10, 2025
These all seem like they might effectively be the same issue:
#29394
#31158
#29719
#28713
#27532
Can anyone here test this with DASHBOARD_VIRTUALIZATION set to
false? I have a suspicion that may fix it. If so, we can probably just disable viewport virtualization when the headless browser is building the screencap.tsator commentedon Oct 7, 2025
Hi! @rusackas, i was having the same problem: some charts were showing up with the loading spinner when exporting the PDF. The suggested solution
worked for me!
Now, when exporting PDF, all the charts display correctly.
I'm on version 5.0 of Superset.
AdityaKothari27 commentedon Feb 5, 2026
This worked for me but I came across a weird bug.
When I click on the menu for dashboard options, the "Refresh dashboard" and "Download" buttons are disabled.
but after pressing Win+Shift+s for taking a screenshot and select the menu as the screenshot region, it gets enabled instantly.
But the pdf does get all the charts though, no more loading symbols.
rusackas commentedon Jul 21, 2026
Dug into this.
Download as PDF/Download as Imagerun client-side throughdom-to-pdf/html2canvasin the user's own browser, not through the headless report worker, so theisCurrentUserBot()bypass that already skipsDASHBOARD_VIRTUALIZATIONfor scheduled reports and thumbnails never kicks in there. Off-screen charts stay unmounted when the snapshot is taken, which lines up with why disabling the flag fixes it for everyone here. Might be worth teachingdownloadAsPdf/downloadAsImageto force a full render before capturing, same as the bot path already does. Seeing if I can track down a fix.jenwitteng commentedon Jul 29, 2026
@rusackas your diagnosis matches exactly what I hit.
Download as Image/Download as PDFcapture the live DOM client-side, so theisCurrentUserBot()bypass that covers scheduled reports and thumbnails never applies, and any row unmounted byDASHBOARD_VIRTUALIZATIONis captured as a<Loading>spinner. Disabling the flag "fixes" it only because every chart then stays mounted.I built a fix for this on our fork a while back and it's held up in production. The approach is the "force a full render before capturing" one you suggested:
superset-force-all-in-view/superset-restore-virtualization.Rowlistens: on force it disconnects its IntersectionObservers and renders; on restore it re-observes.downloadAsImage/downloadAsPdfdispatch the force event, poll until the.loadingspinners inside the capture container clear (timeout + "export may be incomplete" toast), capture, then restore on every exit path (including error/early-return, so a failed export never leaves virtualization disabled for the session). All gated onDASHBOARD_VIRTUALIZATION.Are you still working on a fix? If not, I'm happy to open a PR with this — I have it ready to go. Didn't want to duplicate anything you have in flight.
rusackas commentedon Jul 30, 2026
Thanks for following through with #42561, @jenwitteng. Looks like the right shape for the fix, and CI's green. Reviews/testing encouraged from anyone reading this :)
fix(dashboard): force-render virtualized charts before client-side ex…