Plotly waterfall with offset base: hovertext activated on hover at wrong position

[maciematt]

Recently, when using an offset (a non-zero base parameter) in a waterfall plot in plotly, I noticed that the boxes with hoverinfo were activated when the mouse pointer was in a completely wrong/unexpected place. I've submitted a question about this on StackOverflow, but realized it's quite likely that this is a bug, so I'm posting it here as well. Here's a link to my original post on SO, with a reproducible example: https://stackoverflow.com/q/71655326/3381005. I observed this behavior in the R version of Plotly, but I don't think it's R-specific, as I saw a similar post from a Python Dash Plotly user (sadly unanswered) here.

[maciematt]

I've also prepared a simplified JS waterfall plot with a non-zero base, and it exhibits the same problem: https://codepen.io/pharmhax/pen/popLNQa.

[maciematt]

TL;DR: When hovering over a waterfall plot with a non-zero base parameter, it looks like wrong points are being selected for the hoverOnBars function if we hover above the base value.

Ok, I've investigated this a little more. Forked the repo, set up and started the test dashboard as explained in the contributing doc, I pasted in my test data into the console and created a new plot in the dashboard:

var data = [{
  type: "waterfall",
  orientation: "h",
  x: [0.56, -1.27, 2.14, null],
  measure: ["relative", "relative", "relative", "total"],
  y: ["A", "B", "C", "all"],
  base: -15,
  decreasing: { marker: { color: "orange"}},
}];
var layout = {
  xaxis: {
    ticks: "outside"
  }
}

Plotly.newPlot('graph', data, layout);

Here's the resulting plot:

First, I thought something would be off with the function that detects if we're in the box, so I added a bunch of console.log statements into the hoverOnBars inbox function in src/traces/bar/hover.js:

    function inbox(_minPos, _maxPos, maxDistance) {
        if(opts.finiteRange) maxDistance = 0;

        // add a little to the pseudo-distance for wider bars, so that like scatter,
        // if you are over two overlapping bars, the narrower one wins.

        console.log(`posVal: ${posVal}`);
        console.log(`xval: ${xval}`);
        console.log(`yval: ${yval}`);
        console.log(`_minPos: ${_minPos}`);
        console.log(`_maxPos: ${_maxPos}`);
        console.log(`v0: ${_minPos - posVal}`);
        console.log(`v1: ${_maxPos - posVal}`);
        console.log(`passVal: ${maxDistance + Math.min(1, Math.abs(_maxPos - _minPos) / pRangeCalc) - 1}`);

        return Fx.inbox(_minPos - posVal, _maxPos - posVal,
            maxDistance + Math.min(1, Math.abs(_maxPos - _minPos) / pRangeCalc) - 1);
    }

With this, I started hovering over the plot and noticed that:

• On the bar labeled with "A", the hoverbox never pops up and the _minPos and _maxPos values that show up correspond to "all", not "A".
• For the bar labeled with "B", the hoverbox pops up to the left of the base value, i.e. for x-axis values lower than -15. In that range, the values that pop up in _minPos and _maxPos correspond to the y-axis range of "B". If we go above my base of -15 on the x-axis, the hoverbox disappears, and I get the _minPos and _maxPos values corresponding to "all" again.
• Box "C" behaves the same way as "B", i.e. below -15 on the x-axis the hoverbox shows up and the values in _minPos and _maxPos correspond to the y-axis position of box "C", if we hover over values higher than -15 on the x-axis, _minPos and _maxPos values change to those that correspond to "all", and the hoverbox disappears.
• "all" works correctly.

With this, I thought this problem must have something to do with the "all" bar being erroneously selected when we hover above the base. So, again in hoverOnBars, I added some console.logging where the closest data point is determined:

    // the closest data point
    var index = pointData.index;
    var di = cd[index];
    console.log(`index: ${index}`);
    console.log("di:"); console.log(di);

After hovering over the bars, the output in the console seems to confirm the behavior surmised from position logging above:

• Hovering anywhere within box "A" and along it's whole strip on the x-axis always outputs "index: 3" and no hoverbox.
• For box "B", I get "index: 1" and the box "B" hoverbox when hovering below base (i.e. -15) on the x-axis, and "index: 3" (and no hoverbox) above it.
• For box "C", I get "index: 2" and the box "C" hoverbox below base, "index: 3" and no hoverbox above base.
• For box "all" I get "index: 3" along the whole x-axis strip corresponding to "all", and the "all" hoverbox within the x-axis limits occupied by the "all" box.

So it looks like the pointData objects coming into the function for some reason don't associate with the right points above the base value... The hover calculations in a large part seem correct, but the points that get picked and go into hoverOnBars aren't the right ones.

Not sure when I'll be able to continue with this... Given the above, any ideas on how this problem comes about?

Thanks!

[archmoj]

Thanks for the detailed report.

[maciematt]

just wanted to check back - what's the timeline for fixing this bug?