hovermode="x" is unreliable with multiple traces

[pfbuxton]

In a graph which has two traces with a different number of data points and using hovermode="x" it is extremely difficult to "hover" over the trace with the fewer number of data points.

In the example below it is very difficult to hover on the blue trace which has 150 data points, compared to the orange trace which has 1,500 points.

import dash
import dash_core_components as dcc
import dash_html_components as html
import plotly.graph_objs as go
import numpy as np

app = dash.Dash(__name__)

traces = []

# Make trace with 150 points
x1 = np.linspace(0.0, 1.0, 150)
y1 = np.sin(x1)
traces.append(go.Scatter(
    x = x1,
    y = y1,
    name = '150 data points'
))
# Make data with 1,500 points
x2 = np.linspace(0.0, 1.0, 1500)
y2 = np.cos(x2)
traces.append(go.Scatter(
    x = x2,
    y = y2,
    name = '1,500 data points'
))

app.layout = html.Div(
    children = [
        dcc.Graph(
            figure = dict(data=traces, layout={})
        )
    ],
    style = {
        'width': '500px',
        'height': '600px'
    }
)

if __name__ == '__main__':
    app.run_server(debug=True)

[nicolaskruchten]

Thanks for the clear reproduction steps! Here's the same figure converted to a JS-only codepen: https://codepen.io/nicolaskruchten/pen/zYNovgJ?editors=0010

"compare" hovermode (i.e. "x" or "y") is really intended mostly for well-aligned traces: traces with identical X values. We're doing some work with the hovering logic at the moment though, so maybe we can improve this situation a little bit... @alexcjohnson is hoverdistance intended to only impact the "winning point" in the hover logic? Could/should there be some other distance parameter for the "hover set" ?

[alexcjohnson]

This feels to me like another hovermode, perhaps "x loose". In this mode, independently for each trace we find the best point, if there is one within the hoverdistance considering only the x coordinate. Then we draw one hover label for each trace that looks like the "closest" labels, never creating a common axis label and never combining them like in "x unified", because these features will just be confusing when we're expecting the x values to differ between points. We would still find an overall best point if spikelines were enabled, but only for that purpose.