Fix order of heatmap z-data

[dy]

Should fix #1825

If I get it right, we have rows layout z: [[x,x,x,x], [x,x,x,x], ...], meaning that to retrieve a value we call z[y][x], not z[x][y].

[etpinard]

Hmm. pointNumber should give the z[pointNumber[0]][pointNumber[1]] value.

We'll have to check with if this is consistent with non-gl heatmap and contour.

[dy]

@etpinard yes, we do z[y][x] in regular heatmap: https://github.com/plotly/plotly.js/blob/master/src/traces/heatmap/hover.js#L94

[etpinard]

but on

https://github.com/plotly/plotly.js/blob/master/src/traces/heatmap/hover.js#L38

we set

ny = index[1]
nx = index[0]

[dy]

Not sure where do we use pointData.index !== false branch at all, because in every case I could find we calculate nx, ny here, which is basically snapping proper x/y value to bins, which corresponds to z[y][x] data layout and the way data is plotted.

[etpinard]

See http://rickyreusser.com/plotly-mock-viewer/#zsmooth_methods

[dy]

@etpinard yes, these cases are for regular heatmap, switching them to heatmapgl raises the error covered here.

[alexcjohnson]

but on

https://github.com/plotly/plotly.js/blob/master/src/traces/heatmap/hover.js#L38

we set

ny = index[1]
nx = index[0]

@etpinard looks consistent to me?

nx = Math.round(pointData.index[1]);
ny = Math.round(pointData.index[0]);

Anyway, the convention is meant to match the way a matrix is printed:

[
  [1, 2, 3],
  [4, 5, 6],
  [7, 8, 9]
]

so the first index is row (y) and the second index is column (x)

@dfcreative the pointData.index !== false case may be for manually triggering hover - ala https://plot.ly/javascript/hover-events/#triggering-hover-events (note you have to scroll the iframe to see the "go" button)

How about covering the relevant cases with tests, then we don't have to argue about this!

[etpinard]

It would be nice to fix this thing in 1.29.0. I'll try wrapping this up tomorrow.

[etpinard]

Supersedes by #1884