Fixup hover filters

[archmoj]

Fixes bug mentioned in #5554 (comment),
also simplifies period and non-period hovers in respect to #5553 and #5554.

Also closes #5572 : Demo Before vs After.

And closes #4787 : Demo Before vs After

@plotly/plotly_js

[nicolaskruchten]

With this PR it's possible to get two scatter hovers now:

[archmoj]

With this PR it's possible to get two scatter hovers now:

I was not able to replicate this. Could you please share the figure?

[nicolaskruchten]

https://observablehq.com/@nicolaskruchten/plotly-js-branch-tip-chooser on this current branch. Start with your mouse on the far right and very slowly scan it towards the left. There is a very narrow zone between the two right-most markers where this happens.

[archmoj]

https://observablehq.com/@nicolaskruchten/plotly-js-branch-tip-chooser on this current branch. Start with your mouse on the far right and very slowly scan it towards the left. There is a very narrow zone between the two right-most markers where this happens.

Thanks. Fixed by 3b85534.

[archmoj]

@nicolaskruchten @alexcjohnson I fixed the issues we noticed today and updated the codepens.

[nicolaskruchten]

Wow, this looks pretty great, behaviour-wise, thanks! Nice bug-fixing too 👍

[alexcjohnson]

One concern: looks like a scatter point in the gap between two bars, but clearly within the data range of one of them, can be paired with hover from the other one if the mouse is over that other half of the gap.

Plotly.newPlot(gd,[
    {x:[1,2,3,4],y:[1,2,3,4],type:'bar'},
    {x:[0.6,0.8,1,1.2,1.49,1.75,2.51,3.2,5],y:[3,3,3,3,3,3,3,3,3],mode:'markers'}
],{hovermode:'x'})

[alexcjohnson]

Actually even if the scatter point isn't over the gap, but the gap is small enough compared to the hover distance, you can get the same thing in more severe form:

[alexcjohnson]

The situation I'm describing in the above two comments violates the second rule in #5554:

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)

Note that that rule references "the point that wins the hover" and says nothing about where the cursor is.

[archmoj]

The situation I'm describing in the above two comments violates the second rule in #5554:

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)

Note that that rule references "the point that wins the hover" and says nothing about where the cursor is.

After trying out a number of potential fixes towards enforcing that rule, and after looking at x unified variant I think this cursor dependant behavior might be actually desirable. So perhaps what we need is to relax that rule.

[nicolaskruchten]

@archmoj please expand on why you think this needs relaxing?

[archmoj]

@archmoj please expand on why you think this needs relaxing?

The point at 1.49 wins by hovering at 1.75. There is no harm to display bar at position 2 which is the closest bar. If we instead pick bar at position 1, it would be misleading. Please note that the unified hover is attached to cursor as well.

[nicolaskruchten]

Thanks for the explanation. I still think the invariant as described is the right one but I'll think about it a bit more over the weekend. It's too hard to reason about things if the hover set depends on the cursor position and the winning point IMO.

My next question is how comes a scatter point at 1.49 wins with the cursor at 1.75 if there is a bar at 2? My instinct is to stick with the invariant as described and dig into the winning point logic after 2.0.

[archmoj]

Thanks for the explanation. I still think the invariant as described is the right one but I'll think about it a bit more over the weekend. It's too hard to reason about things if the hover set depends on the cursor position and the winning point IMO.

My next question is how comes a scatter point at 1.49 wins with the cursor at 1.75 if there is a bar at 2? My instinct is to stick with the invariant as described and dig into the winning point logic after 2.0.

Yeah. Let's think about it during weekend.
I mean 1.6 not 1.75...

[archmoj]

The situation I'm describing in the above two comments violates the second rule in #5554:

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)

Note that that rule references "the point that wins the hover" and says nothing about where the cursor is.

OK. I made the adjustment to respect the rule. It doesn't look bad :)

[alexcjohnson]

Looks perfect now! 💃