Hovering on boxes/violins shows only median label under "opposite" hovermode

[konieczny9lives]

When box plot is the only trace, all statistics (min,q1,median,q3,max) are displayed on hover.
If you add another trace as a subplot, only median is displayed on hover.

This only happens with horizontal box plot as far as I know.

Reproduction:
https://codepen.io/kotwgarnku/pen/gdxaPN

[alexcjohnson]

Thanks @konieczny9lives! There's also a very strange interaction between the two plots in that codepen, that sometimes (for example, click "show closest data on hover" in the top modebar) the hover labels for the top plot show up at the positions they should have for the bottom plot !?!

[konieczny9lives]

Great catch @alexcjohnson!

In regard to the original issue, I just found out that if you add hovermode: "closest" to layout options, all statistics (min,q1,median,q3,max) are displayed as intended.

[alexcjohnson]

Well, mostly as intended... they're showing up horizontal (which requires them to be weirdly shifted vertically)

when they should be showing up tilted, which seems to me much more readable:

[etpinard]

Related: #2194

[stargazer33]

It seems, this is the same problem as here:
https://community.plot.ly/t/boxplot-in-a-subplot-very-limited-information-in-hover/13109

It is a “subplot”; a histogram and a boxplot together, they share the X axis.
When I position the mouse cursor over boxplot I see ONLY the median values of both boxplots at the same time!

[etpinard]

After some investigation, lines:

plotly.js/src/components/fx/hover.js

Lines 580 to 582 in 2f0d56e

	// if there's more than one horz bar trace,
	// rotate the labels so they don't overlap
	var rotateLabels = hovermode === 'y' && searchData.length > 1;

,

plotly.js/src/components/fx/hover.js

Lines 657 to 664 in 2f0d56e

	// show the common label, if any, on the axis
	// never show a common label in array mode,
	// even if sometimes there could be one
	var showCommonLabel = (
	(t0 !== undefined) &&
	(c0.distance <= opts.hoverdistance) &&
	(hovermode === 'x' || hovermode === 'y')
	);

and

plotly.js/src/components/fx/hover.js

Lines 760 to 765 in 2f0d56e

	// remove the "close but not quite" points
	// because of error bars, only take up to a space
	hoverData = hoverData.filter(function(d) {
	return (d.zLabelVal !== undefined) ||
	(d[commonAttr] || '').split(' ')[0] === t00;
	});

shed some light on the problem.

---

In the 2-trace (bad) graph in https://codepen.io/kotwgarnku/pen/gdxaPN:

• hovermode is 'x', the default from

plotly.js/src/components/fx/layout_defaults.js

Lines 31 to 32 in 2f0d56e

	layoutOut._isHoriz = isHoriz(fullData);
	hovermodeDflt = layoutOut._isHoriz ? 'y' : 'x';

where isHoriz returns false unless all traces are horizontal and in the codepen above, trace1 is not horizontal.

• searchData has length 1, corresponding to one trace to 'search for' on the xy2 subplot (the trace being the box trace)

• so rotateLabels is false. I'd call this wrong.

• next stop, showCommonLabel is true and

• this result in the box hoverData (corresponding to the mean, q1, q3, ... labels) being filtered down to a single label.

---

So, here's a few conclusions:

• We should fix the logic for rotateLabels, it should take into consideration cases where searchData has length 1 but hoverData.length > 1. This should ✅ non-linear box/violin hover label quirks #2194 - easy.
• We should also make rotateLabels true when hovering under an "horizontal" trace under hovemode: 'closest'. This would fix the "mostly intended" hiccup described in @alexcjohnson 's Hovering on boxes/violins shows only median label under "opposite" hovermode #2970 (comment)
• But this won't be enough to fully fix https://codepen.io/kotwgarnku/pen/gdxaPN
  • rotateLabels will still be false (as hovermode: 'x' from that scatter trace)
  • hoverData will still get filtered down to a single label (as showCommonLabel is true)
• Unfortunately, I don't see an easy solution that doesn't lead to a breaking change, where we make 'closest' the hovermode default (see Smarter defaults for layout.hovermode #778)

[etpinard]

PR #3043 fixes the cases under hovermode: 'closest', but did not attempt to fix:

• horizontal box/violin with hovermode: 'x'
• vertical box/violin with hovermode: 'y'

[alexcjohnson]

The misalignment in the original multi-plot codepen https://codepen.io/kotwgarnku/pen/gdxaPN when you set the first plot to closest is still there (and yes, the codepen is now using 1.41.3). To be clear, I'm talking about how eg the "min" label is not pointing to the "min" value, but to where that value would be according to the bottom plot. There also seems to be a problem with the overlap avoidance algorithm when one of the labels is too long and gets flipped to the top - it's putting them out of order and then stretching them across each other.

[etpinard]

There also seems to be a problem with the overlap avoidance algorithm when one of the labels is too long and gets flipped to the top - it's putting them out of order and then stretching them across each other.

Ha I see. This probably deserves an issue of its own.

[etpinard]

#2970 (comment) is now in -> #3050

[jackparmer]

This issue has been tagged with NEEDS SPON$OR

A community PR for this feature would certainly be welcome, but our experience is deeper features like this are difficult to complete without the Plotly maintainers leading the effort.

Sponsorship range: $5k-$10k

What Sponsorship includes:

• Completion of this feature to the Sponsor's satisfaction, in a manner coherent with the rest of the Plotly.js library and API
• Tests for this feature
• Long-term support (continued support of this feature in the latest version of Plotly.js)
• Documentation at plotly.com/javascript
• Possibility of integrating this feature with Plotly Graphing Libraries (Python, R, F#, Julia, MATLAB, etc)
• Possibility of integrating this feature with Dash
• Feature announcement on community.plotly.com with shout out to Sponsor (or can remain anonymous)
• Gratification of advancing the world's most downloaded, interactive scientific graphing libraries (>50M downloads across supported languages)

Please include the link to this issue when contacting us to discuss.

[gvwilson]

Hi - this issue has been sitting for a while, so as part of our effort to tidy up our public repositories I'm going to close it. If it's still a concern, we'd be grateful if you could open a new issue (with a short reproducible example if appropriate) so that we can add it to our stack. Cheers - @gvwilson