Inconsistent datetime hoverinfo with Scattergl and datetime axis

[slishak]

Following on from the suspected regression of #2334, I also noticed a slightly different issue.

In this plot, both Scattergls are plotted with hoverinfo: 'x+y'. However, trace 1 only has y in the hover label, and trace 2 has y but sometimes also x (but only when hover labels for both trace 1 and 2 are plotted at the same time, and even then not consistently).

https://codepen.io/anon/pen/xyNLKL

[alexcjohnson]

This happens when the two traces have nearly but not quite identical x values. They’re close enough that it makes sense to compare them, but we need to show both x values because they are, in fact, different, and we want to make the viewer aware of this. You’re right though that it looks odd, I’m open to suggestions to improve it.

[slishak]

Although obviously related, to me that doesn't seem to be exactly what's happening here:

• If x is in hoverinfo, shouldn't the x values always be shown in the hover label?
• The x value is never shown for the blue trace, even when it is shown for the orange trace (as per your comment, both x values should be shown in this situation)

As an aside - is there any way to control the threshold of how close two x values can be before they're identified as nearly identical? Because I have some cases where I'd want to set this to 0 (i.e. only ever show hover labels for identical discrete x values) or a larger number (to allow for more tolerance with slightly misaligned continuous time series, for example) or even just perform linear interpolation if possible.

[alexcjohnson]

• If x is in hoverinfo, shouldn't the x values always be shown in the hover label?
• The x value is never shown for the blue trace, even when it is shown for the orange trace (as per your comment, both x values should be shown in this situation)

When you're in "compare" mode we try to identify a "common label" for x (or for y, in case of eg horizontal bars), and this label is drawn on the axis - the black label in your gif. Then any individual label that has 'x' in its hoverinfo, if the label matches the common label we don't show it in the individual label since it's already there in the common label. So for the blue trace, x is shown, just not in the blue label.

Incidentally, #3126 will provide one way around this, since you'll be explicitly specifying the format for each label. I suspect after that PR, if all traces have a hovertemplate the common label won't be created at all, only the trace labels.

As an aside - is there any way to control the threshold of how close two x values can be before they're identified as nearly identical?

The logic is a bit convoluted... in some cases layout.hoverdistance may be useful for you, but in the case you posted, since the tolerance you'd want is smaller than the marker size here (and hoverdistance only controls how far outside the marker you can still hover on a point, it always accepts the interior of a marker) it won't help this case. I suppose in your particular case, since there are multiple essentially equivalent points (until you zoom in a lot) it would in principle be possible for us to change how we search, to prioritize matching x values over the precisely closest point in each trace. That sounds awfully complicated though, and thus likely to have unintended consequences, and also would only help in limited cases, where x values either match precisely or are missing from some traces like your example. It wouldn't help when the values are simply misaligned.

or even just perform linear interpolation if possible.

proposed in #1960

[slishak]

Ah I see, thanks for the explanation! So in the end, everything here is working as expected, even though it feels slightly odd at first. Can be confirmed by setting hovermode to closest, which gives me back the x info in the hover label.

So if I understood correctly - even if there were some threshold we could use to control how different two x values have to be before they're considered close enough to draw both hover labels, in this example the mouse would always be over a marker from both lines (because hoverdistance is defined from the edge of the marker, not the datapoint itself, and every point is within the x extents of a marker from both traces until you zoom in).

However, in other cases, layout.hoverdistance achieves what I'm looking for, so thanks for that!

Back to the topic at hand - I don't have any ideas for improving this behaviour. It seems logical
now that you've explained it, especially now I understand that having x in the hoverinfo doesn't mean it has to be shown on the label instead of the axis. No objection to closing the issue from me.

[alexcjohnson]

OK great - I'll close it as we don't have a clear action item, but you're right that it has some quirks. If any future readers have a concrete suggestion for improving this feel free to reopen!

[slishak]

(although I forgot to reiterate that maybe #2334 (comment) should be reopened? or should I create another issue?)