[Bug] Horizontal Legend Wrapping doesn't account properly for usage of <br> tags

[Braintelligence]

Reproduction:

1. Set screen size so narrow that all legend items will be displayed in a vertical fashion, with legend.orientation = "h".
2. Create two traces where the first one has a very long name that will make the second trace's name wrap into the next line and do not use <br> in the first traces name.
3. Put at least one <br> in the second trace's name.

Here's an example: https://codepen.io/anon/pen/EdJyQm?editors=0010

If you put a <br> anywhere in the name of trace6, the name of trace7 will be shown fine.
If you leave it out and your last trace contains a <br> the second line will be cut off.

Please ping me up if you need further explanation of the problem.

[Braintelligence]

Actually it seems that the last legend item with <br> will be cut off if there is any other legend item without <br>. This is a significant bug that I don't know how to take care off, other than conditionally switching to legend.orientation = "v" if a certain clientWidth is underrun.

EDIT:
Actually it seems that if the first element of all legend items contains the same amount of <br> as the last element, there is no problem.
Could it be that the "margin" for the legend is calculated solely by the first element?

[Braintelligence]

@alexcjohnson Do I understand correctly that maxTraceHeight is set to 0 here

plotly.js/src/components/legend/draw.js

Line 594 in 9a79056

maxTraceHeight = 0,

and then used for calculations here

plotly.js/src/components/legend/draw.js

Line 615 in 9a79056

rowHeight = rowHeight + maxTraceHeight;

(even though it never could amount to anything but 0 and only after that it is being set to anything at all

plotly.js/src/components/legend/draw.js

Line 630 in 9a79056

maxTraceHeight = Math.max(legendItem.height, maxTraceHeight);

Or do I miss something here?

EDIT: Ah, it's a forEach. But then how is maxTraceHeight relevant for the last legend item? It is calculated but never used then. Am I right?

[Braintelligence]

So I verified the behaviour and can reproduce it 100%:

Either the first trace/a trace in the first row has to contain the same amount of <br> as the last trace/all traces in the last row: https://codepen.io/anon/pen/pxmwZz?editors=0010

Or any trace in between (rows) has to contain at least the same amount of <br> as the last trace/all traces in the last row + 1 more <br>: https://codepen.io/anon/pen/MPdoXY?editors=0010

Something must be different for the first legend item/first row calculation that doesn't apply to all other legend items. What could that be?

EDIT: Man, this is the only wall I've hit yet that I couldn't program a somewhat efficient workaround for. 🙈 The only things that I can think of would be heavily resource-hungry...

[Braintelligence]

Hey, everyone. Just wanted to know if anyone of the contributors/members has read this, since it isn't labeled and there's no comment yet =(...

[etpinard]

#3024 might be enough to fix this.

[Braintelligence]

Just for the record: I found another problem with this. If you have <br> in your trace.name the white background doesn't follow properly and the name collides with the next trace:

[etpinard]

Sorry for not taking a more serious look at this report before. Turns out this thing is a different beast than what #3024 attempts to solve.

@Braintelligence in

• https://codepen.io/anon/pen/pxmwZz?editors=0010 and
• https://codepen.io/anon/pen/MPdoXY?editors=0010

can you confirm that switching to legend.orientation: 'v' gives the correct result?