This looks good AFAICT! @alexcjohnson can we get an expedited review plz?

Looking specifically at the test I commented on above but having fixed the typo, here's the behavior on master:

It's not perfect, I don't think we should be showing Jan while the cursor is over the first half of Feb, but otherwise I actually think it looks correct: the spikeline shows the point that wins and the hover label shows all traces that match that period and it's positioned at one edge of the period.

Here's the behavior currently with this PR:

Now the hoverlabel is positioned at the spikeline regardless of the period, it very often does NOT contain all the traces with points in a matching period, and when you do get multiple traces you mix points representing different periods - with some very weird flipping between two winning points right around the period boundary.

I thought at one point we had the idea that a period-positioned scatter trace should behave like a bar for hover purposes, in that any given point should be included in the hover whenever your cursor is over the period it represents. Did we drop that idea?

a period-positioned scatter trace should behave like a bar for hover purposes

Yes, here are the period-positioning invariants: #5553

The behaviour you note above is indeed troubling. Which mock is this?

I'm also seeing some odd spikeline/hover mismatches in the all-bar case: https://codepen.io/nicolaskruchten/pen/bGWoVKB?editors=0010

It's this, from the test I commented on:

var scatterType = 'scatter';
Plotly.newPlot(gd, {
                data: [
                    {
                        name: 'bar',
                        type: 'bar',
                        x: ['2000-01', '2000-02'],
                        y: [1, 2],
                        xhoverformat: '%b',
                        xperiod: 'M1'
                    },
                    {
                        name: 'start',
                        type: scatterType,
                        x: ['2000-01', '2000-02'],
                        y: [1, 2],
                        xhoverformat: '%b',
                        xperiod: 'M1',
                        xperiodalignment: 'start'
                    },
                    {
                        name: 'end',
                        type: scatterType,
                        x: ['2000-01', '2000-02'],
                        y: [1, 2],
                        xhoverformat: '%b',
                        xperiod: 'M1',
                        xperiodalignment: 'end'
                    },
                ],
                layout: {
                    showlegend: false,
                    width: 600,
                    height: 400,
                    hovermode: 'x unified'
                }
            })

Better, it's now consistently showing all the traces I think it should. I still think we need to push the hover label outside the period the winning point represents, and right now it seems the hover label and spike line positions are referenced to different points: the label at the first (?) point in the hover set, but the spike line at the winning point. For example in the period_positioning3 mock, with my cursor near the end of May, I can't see the brown point or most of the red point being hovered on, and the spike line is obscured:

Agreed with Alex's point above: the hoverlabel should always be to the side of the spikeline (as it is on master I believe)

With this build, I don't seem to be able to hover on the left-most points in the figure from #5822 ... see https://codepen.io/nicolaskruchten/pen/MWmEzeJ?editors=0010

With this build, I don't seem to be able to hover on the left-most points in the figure from #5822 ... see https://codepen.io/nicolaskruchten/pen/MWmEzeJ?editors=0010

Good catch. Thank you!

But I can see your argument, I'd be OK with pushing the label back to the spike line at least when it's a scatter point that wins. I think if it's a bar that wins it's still better to push it to the edge of the bar, and in fact to the edge of the bar group when we're labeling the whole group.

@archmoj can we do this please? When the scatter point wins, it's ok for the hovelabel to occlude the bar.

Good idea. Applied in 16f4554.

It's still possible to have the hover label occluding the spikeline - hover on the right half of any period in period_positioning3

I think this is a case of the spike line not matching the hover-winning point, which is indeed a bug, and it seems worse with this PR than on master. Can we see if there's a fix for it plz?

It's still possible to have the hover label occluding the spikeline - hover on the right half of any period in period_positioning3

That's simply because of "When the scatter point wins, it's ok for the hovelabel to occlude the bar" logic added in 16f4554. Without it there would be no occlusion with spikeline :)

I think this is a case of the spike line not matching the hover-winning point, which is indeed a bug, and it seems worse with this PR than on master. Can we see if there's a fix for it plz?

This is also true : )

Let's try to fix the spike line position too please before merging this. It should not be possible for the spike line to be on a different point that the winning point: there's a specific attribute for that.

Let's try to fix the spike line position too please before merging this. It should not be possible for the spike line to be on a different point that the winning point: there's a specific attribute for that.

On it.

Let's try to fix the spike line position too please before merging this. It should not be possible for the spike line to be on a different point that the winning point: there's a specific attribute for that.

Done in dca5b1e.

Closer! So in this pen: https://codepen.io/nicolaskruchten/pen/xxdPKwZ?editors=0010 when I hover over the left-most point I get no bar in the hoverlabel, and when I hover on the next point I get the left-most bar in the hoverset. This is even more apparent when hovermode = 'x'.

I should add that the vertical position over the hoverlabels seems too low in this pen: https://codepen.io/nicolaskruchten/pen/QWvOLjJ?editors=0010 ... the hoverlabel is always around the bottom two points for me.

I should add that the vertical position over the hoverlabels seems too low in this pen: https://codepen.io/nicolaskruchten/pen/QWvOLjJ?editors=0010 ... the hoverlabel is always around the bottom two points for me.

Good catch. Fixed in df6353d

Closer! So in this pen: https://codepen.io/nicolaskruchten/pen/xxdPKwZ?editors=0010 when I hover over the left-most point I get no bar in the hoverlabel, and when I hover on the next point I get the left-most bar in the hoverset. This is even more apparent when hovermode = 'x'.

That's a bug.

Closer! So in this pen: https://codepen.io/nicolaskruchten/pen/xxdPKwZ?editors=0010 when I hover over the left-most point I get no bar in the hoverlabel, and when I hover on the next point I get the left-most bar in the hoverset. This is even more apparent when hovermode = 'x'.

That's a bug.

Addressed in 9217db4.

OK, this last set of changes nails down everything I care about! There's still some oddity around end-positioned grouped-bars but we can leave that out for now.

@alexcjohnson over to you, again :)