Scrolling horizontally with a draggable lifted offsets the drop zone relative to the distance I've scrolled

[humphreybc]

Bug or feature request?

I'm not entirely sure. I can't reproduce it in your storybook, which makes me think it's an implementation detail of our particular board. But it could also be a bug.

Expected behavior

On a ‘board’ layout, when lifting an item in the first column, and dragging it across to the right of the screen to drop it into a far column outside the viewport, I should be able to drop it correctly.

Actual behavior

On a ‘board’ layout, when lifting an item in the first column, and dragging it across to the right of the screen to drop it in a far column outside the viewport, I can't drop it, because the drop zone is ‘offset’ the same distance as I've scrolled.

Any suggestions as to why this could be happening would be awesome.

Browser version

Chrome 64.0.3282.186 on Mac OS X 10.13.3.

Demo

[alexreardon]

I suspect you are running into this #362.

The required change would be #131

It is hard to look into it deeper without a stand alone example. Here is our boilerplate https://codesandbox.io/s/k260nyxq9v

[humphreybc]

Okay, thanks. I'm pretty sure this is the same issue then. It's a real bummer. We're so close to having the fixed height columns work perfectly. There are quite a lot of usability advantages to fixed height columns: the ‘new’ button in each column is always within the viewport, when picking something up from the bottom of one column, you don't have to scroll up the page to move to the top of another column, etc.

[12tp12]

@humphreybc hey, did you fixed it? I get the same thing

[humphreybc]

@12tp12 No, I don't think it can be easily fixed until the library supports nested scroll containers.

[crapthings]

you can set parent width to fit-content
https://developer.mozilla.org/en-US/docs/Web/CSS/fit-content

[alexreardon]

Cause: #131

I hope we can look into that one soon 💃