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
- [X] I have searched Superset docs and Slack and didn't find a solution to my problem.
- [X] I have searched the GitHub issue tracker and didn't find a similar bug report.
- [x] 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.
Comment From: sfirke
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?
Comment From: rusackas
I think this is a duplicate of https://github.com/apache/superset/issues/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.
Comment From: sfirke
@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
Comment From: Xyrai
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-sdk NPM 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?
Comment From: nandwalritik
@sfirke Same Issue occurs when downloading as image, any fix available for above bug?
Comment From: kgabryje
I think this might be fixed by https://github.com/apache/superset/pull/29272 (CC @geido)
Comment From: Xyrai
Still seems to be broken on my side sadly while using superset-ui/embedded-sdk. I tried a workaround where you have to adjust the iframeSandboxExtras options and include allow-modals to it. This way you can focus on the iframe via the DOM tree and fire a window.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"
Comment From: 123srikan
any update on this issue.
Comment From: MNITD
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:
- we disabled the virtulaization feature by changing the superset config (docker/pythonpath_dev/superset_config_docker.py)
- inside the config we updated the FEATURE_FLAGS variable:
FEATURE_FLAGS = {
"DASHBOARD_VIRTUALIZATION": False,
}
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 👀
Comment From: geido
Thanks, looking into it
Comment From: zachoooo
That's really interesting. It sounds like maybe virtualization just needs to be disabled when downloading.
Comment From: rusackas
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_THUMBNAILS is enabled.
Comment From: rusackas
These all seem like they might effectively be the same issue:
https://github.com/apache/superset/issues/29394 https://github.com/apache/superset/issues/31158 https://github.com/apache/superset/issues/29719 https://github.com/apache/superset/issues/28713 https://github.com/apache/superset/issues/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.