Regression with horizontal resizing of table headers

[ssunday]

Overview of the problem

#827 seems to have created a regression when using this component to horizontally resize columns in a table—when you click the resize-enabled boundary between the headers (like the border if you have it visibly differentiated), it doesn't resize from the point you are clicking, but of the next column and opposite to how you are dragging.

Like if I grab the right side of a table header and drag it to the right, you expect that the header grows to the right. With this issue, the NEXT column actually shrinks and then going left increases the size of the next column, rather than changing the size of the column I am clicking on.

I'm guessing the issue is that the goal of that ordering conflicts with a table header resize use case. Maybe we make it optional or a prop or something? The issue does not exist in the previous version hence why I'm connecting it to #827 .

I'm using re-resizable 6.10.0

My browser is: Safari/Chrome I believe

I am sure this issue is not a duplicate? Yes

[felixhabib]

I've encountered a similar issue with #827. The change puts the topLeft, top, topRight and left resizable handles before the children in the DOM (ref). Depending on the layout used, this can cause the handles to be stacked below the children, preventing them from being selected.

To get the previous functionality, we had to provide an explicit zIndex for these handles - seek-oss/playroom#374.
Perhaps these need to be provided a higher zIndex than the children in this library?

[bokuweb]

Sorry I'll revert it for now.
#836

@t-hamano Sorry I'll revert PR for now, because we ran into some regressions. I'll reconsider about focus order later.

[bokuweb]

@ssunday @felixhabib v6.10.1 published 🙏