dragging elements on left border causes `deltaX` to jump between negative and positive values
See original GitHub issueThis issue is a copy of https://github.com/STRML/react-resizable/issues/38 because it looks like the root cause is something within this library.
I have a resizable div which is float: right. The handler is on the left side. Everything works fine when the handler is on the right side but I’m having some troubles with the one on the right.
The following gif shows two screens. One, where the resizable is floating left and one where it’s floating right. The floating left example is included to show you that it generally works.

After some debugging and seeing that it works fine if I scale the inner element only, I believe that the issue is caused because the origin of the element wrapping resizeable (which is top left I guess?) changes:

In pseudocode, the react structure of the borken example is:
<div width="123px" float="right">
<ReactResizable>
<children />
</ReactResizable>
</div>
The react structure of the example without jumping is:
<div float="right">
<ReactResizable>
<div width="123px">
<children />
</div>
</ReactResizable>
</div>
In the first case, <ReactResizable> changes the position of the top left corner, which might have something to do with the jumping. In the second, the position of <ReactResizable> stays the same while the right side of the <div> is being changed.
I believe that the root cause for this issue is this library (react-draggable), because:
deltaX in resizeHandler is jumping around between negative and positive values when the issue occurs:
This does not happen when dragging an object on the right side, which is working fine:
resizeHandler is a DraggableEventHandler, so the wrong values are originating somewhere here.
Issue Analytics
- State:
- Created 7 years ago
- Comments:10 (7 by maintainers)

Top Related StackOverflow Question
Thank you! I pulled myself together and dug through the code. The issue, as suspected, is caused by the parent element whose width and position are changing. I was able to fix this issue by forcing to always use
document.bodyand0,0as the origin in domFns.es6:Do you think that this will have negative side effects? If not, I would happily create a PR. If yes, I will try to recreate this issue on esfiddle.
I could really use some help here, this library is a larger one and it is really hard to find the cause by oneself without knowing about the internals. It is very unfortunate to see that despite my attempts to give you as much insight as possible, this issue is simply being ignored although activity on other issues exists by major contributors like @STRML . Maybe I’ll save the troubles next time with recording gifs and debugging and just write: “you lib is broken kkthxbye”. Open sourcing things is also about supporting the community who uses it. Simply ignoring (maybe more difficult) issues isn’t cool.
Having said that, I would love to fix this with a PR but I need guidance to look in the right places.