Hover rules for non-period-positioned bars

[nicolaskruchten]

The new hover invariants in both compare and unified hovermodes for bars that are not period-positioned are:

• the bar cannot win the hover if the cursor is not within the range of the bar (bar.x +/- width/2)
• the bar is in the hover set if-and-only-if the point that wins the hover is within the range of the bar (bar.x +/- width/2)

N.B. (bar.x +/- width/2) here includes the gap

[nicolaskruchten]

In the case of very-narrow bars, we might need some pixel minimum?

[nicolaskruchten]

Open questions:

1. does the code already basically intend to do this?
2. do we need to find specific cases where these are not met?

[nicolaskruchten]

For very-narrow bars, it seems like what's on master already either does this or closely-approximates it: {data: [{ type: "bar", x: [1, 10, 1000], y: [1, 2, 3] }] }

[nicolaskruchten]

And if I add a scatter trace, then the scatter rules about the winning point take over, and then the bars get pulled into the hoverset in a compatible way to the invariants above:

{
  data: [
    { type: "bar", x: [1, 10, 1000], y: [1, 2, 3] },
    { type: "scatter", x: [1, 10, 1000], y: [1, 2, 3] }
  ]
}

[nicolaskruchten]

@archmoj can you please take a close look at this issue this week and see if you can find any cases where, assuming that #5618 is merged, we are not in compliance with these invariants?

[nicolaskruchten]

To recap what we discussed in Slack today... in the pen here https://codepen.io/MojtabaSamimi/pen/QWpKvPO it should not be possible to get just a single scatter point in the hoverset in compare or unified modes.

[nicolaskruchten]

Also, please note that the intent of this issue is bar traces only. Let's discuss box traces in another issue.