[BUG]: Small treemap sectors can disappear
Maintainer antworten meist innerhalb von 1 Tag
@emilykl arbeitet bereits daran.
Seit 07.1.2026.
Bewertung
Dieses Issue wurde noch nicht bewertet.
Beschreibung
Hi, and thank you for creating Plotly and Dash! We ran into a concerning bug with the treemap plots that is causing us problems.
Description
Certain small sectors in a treemap can become disappear entirely. Their visibility changes as the size of the treemap container changes (e.g. as the web browser is zoomed in / out). I don't think the treemap we are creating is especially unusual (it has less than 100 sectors).
This is a very severe problem for us, because we need to rely on the treemap being a faithful representation of the underlying data.
Screenshots/Video
Please see the GIF below (using the Python code shown in this post).
Notice the orange sector labelled #55 (and the purple and dark green sectors above it) that the cursor highlights. When the GIF begins (and the browser is zoomed to 100%), these sectors are visible. However, as we zoom the browser, they disappear and reappear.
I used Firefox's "Inspect Element" tool to examine the orange sector's SVG element. This demonstrates that, when #55 "disappears", it does not just become too small to see -- it becomes completely invisible, as evidenced by its d="..." attribute suddenly being set to "".
Steps to reproduce
Relevant Plotly / Dash versions
$ pip list | grep plotly
plotly 6.5.0
plotly-cloud 0.1.0
$ pip list | grep dash
dash 3.3.0
dash-bootstrap-components 2.0.4
dash_cytoscape 1.0.2
Small example demonstrating the bug
#! /usr/bin/env python3
import plotly.graph_objects as go
from dash import Dash, dcc
names = ['#1', '#2', '#3', '#4', '#5', '#6', '#7', '#8', '#9', '#10', '#11', '#12', '#13', '#14', '#15', '#16', '#17', '#18', '#19', '#20', '#21', '#22', '#23', '#24', '#25', '#26', '#27', '#28', '#29', '#30', '#31', '#32', '#33', '#34', '#35', '#36', '#37', '#38', '#39', '#40', '#41', '#42', '#43', '#44', '#45', '#46', '#47', '#48', '#49', '#50', '#51', '#52', '#53', '#54', '#55', '#56 – 58 (28-node components)', '#59 – 62 (27-node components)', '#63 – 69 (26-node components)', '#70 – 74 (25-node components)', '#75 – 79 (24-node components)', '#80 – 82 (23-node components)', '#83 – 95 (22-node components)', '#96 – 106 (21-node components)', '#107 – 112 (20-node components)', '#113 – 129 (19-node components)', '#130 – 145 (18-node components)', '#146 – 160 (17-node components)', '#161 – 175 (16-node components)', '#176 – 197 (15-node components)', '#198 – 222 (14-node components)', '#223 – 240 (13-node components)', '#241 – 285 (12-node components)', '#286 – 334 (11-node components)', '#335 – 373 (10-node components)', '#374 – 427 (9-node components)', '#428 – 504 (8-node components)', '#505 – 610 (7-node components)', '#611 – 737 (6-node components)', '#738 – 907 (5-node components)', '#908 – 1,206 (4-node components)', '#1,207 – 1,823 (3-node components)', '#1,824 – 3,747 (2-node components)', '#3,748 – 8,004 (1-node components)', 'Components']
parents = ['Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', 'Components', '']
values = [6123, 156, 135, 101, 97, 95, 72, 63, 60, 58, 57, 57, 56, 55, 55, 54, 48, 45, 43, 43, 42, 42, 40, 38, 37, 37, 37, 35, 35, 34, 34, 34, 34, 33, 33, 33, 33, 33, 33, 32, 32, 32, 32, 31, 31, 31, 31, 31, 30, 30, 30, 30, 30, 30, 29, 84, 108, 182, 125, 120, 69, 286, 231, 120, 323, 288, 255, 240, 330, 350, 234, 540, 539, 390, 486, 616, 742, 762, 850, 1196, 1851, 3848, 4257, 28064]
# move some sectors (everything to the right of #55) to be children of a new sector named "Small Components"
i = names.index("#55")
for x in range(i + 1, len(names) - 1):
parents[x] = "Small Components"
num_in_small = sum(values[i + 1: len(values) - 1])
values.insert(-1, num_in_small)
names.insert(-1, "Small Components")
parents.insert(-1, "Components")
app = Dash()
app.layout = [
dcc.Graph(
figure=go.Figure(
go.Treemap(
labels=names, parents=parents, values=values, branchvalues="total", sort=False
)
)
)
]
app.run(debug=True)
Notes
-
This problem impacts both
px.treemapandgo.Treemap. -
This problem impacts both Firefox (v146.0) and Chromium (v143.0.7499.40).
-
The problem only seems to occur when we use
sort=Falsewhen creating the treemap. (However, maybe this is just because this changes the location of the small sectors? I suspect this problem is still possible to reproduce withoutsort=False.) -
The problem only seems to occur when the treemap has multiple layers -- that is, when we add the
Small Componentsrectangle above. If we don't do this, then these sectors can still get really small, but they can still at least be hovered over with the mouse. -
Looking through past bug reports, two things that seem relevant are #5209 and this Plotly Forum post.
-
If fixing the bug is not possible, it would at least be helpful for Plotly to somehow emit a warning that the treemap is not accurately rendering the data. I think it would be possible to write some Dash / JS code that scans through the SVG and flags any
d=""elements (and then warns the user if we find any), but hopefully that is unnecessary.
- Vorherrschende Sprache
- Python
- Sterne
- 18.8k
- Forks
- 2.8k
- Ø Merge
- 13 Std. 28 Min.
- Gemergte PRs (30 T.)
- 20
Entwicklungsumgebung
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus plotly/plotly.py
-
P3 size: 1 task
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 65/100
plotly/plotly.py#5769 · 1 Reaktion ·
Maintainer antworten meist innerhalb von 1 Tag
-
P3 size: 1 task
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
Maintainer antworten meist innerhalb von 1 Tag
-
bug P1
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 68/100
Maintainer antworten meist innerhalb von 1 Tag
-
feature P3
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 62/100
Maintainer antworten meist innerhalb von 1 Tag
-
feature P3
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
plotly/plotly.py#3859 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
Alle Issues in plotly/plotly.py
Ähnliche Issues
-
needs triage
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
Maintainer antworten meist innerhalb von 2 Tagen
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
openvinotoolkit/openvino_notebooks#3665 ·
Maintainer antworten meist innerhalb von 1 Tag
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 86/100
Maintainer antworten meist innerhalb von 1 Tag
-
docs
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 88/100
Maintainer antworten meist innerhalb von 1 Tag
-
benchmark-gap
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
Maintainer antworten meist innerhalb von 1 Tag