[BUG]: Small treemap sectors can disappear

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.treemap and go.Treemap.

• This problem impacts both Firefox (v146.0) and Chromium (v143.0.7499.40).

• The problem only seems to occur when we use sort=False when 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 without sort=False.)

• The problem only seems to occur when the treemap has multiple layers -- that is, when we add the Small Components rectangle 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.