Hovering over super-imposed pts (only) considers hoverinfo of top trace

[bxlxux]

Hello - I came across this bug #493 though I'm not sure it's the same issue.

I have this test codepen running with "hovermode":"closest" set. The text displays when hovering over the lines. However, when I change the cdn to 1.10.1 or later the hover no longer works. I can only get the text to display when removing "hovermode":"closest", but it's displaying all text based upon x and not the way I'd like it to which is "closest".

http://codepen.io/bxlxux/pen/jALWAK

[etpinard]

Thanks for the report.

Here's a more compact reproducible example: http://codepen.io/etpinard/pen/ZOJQyk?

To note, the problem is also present on master and seems to be only affecting scattergeo traces with mode set to lines. Changing the issue title accordingly.

[etpinard]

Oh wait. My mistake your example isn't a scattergeo graph.

The problem is in the cartesian hover code.

Preliminary diagnostic: Hovering of superimposed picks the top trace and honours the hoverinfo setting present in that last trace. For example, if the top trace has hoverinfo: 'none' then no hover labels are shown.

See #438, #495 and #678 for more info on the topic.

Thanks again for this report. In the meantime here's an easy workaround: http://codepen.io/etpinard/pen/qNXNwz

where simply reordering the traces gets you back to the desired behaviour.

[etpinard]

More generally,

Should hovering over super-imposed traces on hovermode: 'closest' show multiple hover labels?

[etpinard]

Ok. I found a way to fix this (see closest-hoverinfo-none) but I'm not convinced it is the way to go.

At the moment, hovering with hovermode: 'closest' over super-imposed points picks out the most above point - regardless of its hoverinfo value. The same point is used to dispatch plotly_click and plotly_hover info - which a priori should not care about the hoverinfo value.

So, in order to make the picked point consistent across hover label, plotly_click and plotly_hover, I propose in #678 to add a hoverinfo value to distinguish between traces that should be only hidden on hover (but can still trigger plotly_click and plotly_hover) and traces that should be completely ignored by the picking routine.

[bxlxux]

Thanks for the quick reply! Unfortunately my javascript skills are limited so I may not be able to meaningfully contribute. I did take the javascript from your codepen (http://codepen.io/etpinard/pen/qNXNwz) and add that to my original pen (http://codepen.io/bxlxux/pen/jALWAK).

I understand the simplification, but since we're running a batch process to generate over 100+ charts our json gets written into a script tag within the html file rather than a url variable you used. That's why it's quite lengthy.

So if you looked at my pen http://codepen.io/bxlxux/pen/jALWAK, how could I point to the json? I think this works if I can get the that sorted. Thanks!

[etpinard]

I'm not sure I understand your question.

All you need to get back the desired behavior is to reorder your traces such that the above superimposed trace does not have hoverinfo: 'none'.

[bxlxux]

Okay I see what you're saying. I guess the change in 1.10.1 requires us to do this reordering of traces that we didn't have to do in 1.10.0. We manually changed the hoverinfo to none for several of the objects in our map like the points indicating the city, because we added them to the tooltip on hover. It would be nice to not have to reorder the traces since we have over 100+, but alternatively we can stick with 1.10.0.

[bxlxux]

Changing the order in which we add the various geometric layers to the plot in R (adding the tooltips last with "hoverinfo":"text" set) allowed us to have the tooltips work again with 1.10.1-1.14.1. Thanks!

[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