Root element noop blocking GSAP Draggable
See original GitHub issueDo you want to request a feature or report a bug? Honestly I don’t know
What is the current behavior?
I’m a moderator in the GreenSock forums and the most recent update (16.5.X) is causing some issues with the Draggable tool. By default the Draggable tool ignores clicks on specific elements so by default those are not draggable elements, unless you specify that the element should be draggable. Starting on version 16.5.0 a noop function is passed on the onclick event of the root element of a react app, which is preventing a simple <div> tag from being used by the Draggable tool.
**If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn’t have dependencies other than React. https://codesandbox.io/s/jrkbkxeqy The blue square is not draggabl(should rotate). If you either uncomment line 24 or change the React and ReactDOM versions to 16.4.2,
What is the expected behavior? It shouldn’t be necessary to add the indication to make the element Draggable, it should work by default just in any regular application or web page.
Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React? React: 16.5.0 - 16.5.1 Chrome 69 - Firefox 62 - IE11 - Edge 17 Windows 7 64 Also other users have tested in Chrome and Firefox in OSX (don’t know specific versions)
Issue Analytics
- State:
- Created 5 years ago
- Reactions:1
- Comments:5 (3 by maintainers)

Top Related StackOverflow Question
Hi @gaearon, thanks for addressing this. I think the best way to move forward here is for us to change the default behavior in Draggable to dragClickables:true. That way, you don’t need to do anything in React and if people want to disallow dragging clickable elements, they can just set dragClickables:false.
To answer your question, yes, it should resolve things if you switched from declaring an onclick to addEventListener(“click”…) but I totally see your point about the fragility, hence my recommendation to just switch behavior on our end. The down side for us, of course, is that this change could break some legacy code but I doubt it’ll be a widespread problem and there’s an easy fix (setting dragClickables:false).
We’ll plan on making this change in our next GSAP release.
Thanks again for your consideration. And thanks, @rhernandog, for reporting this!
I think we ended up changing this back (except for portal roots – kept a targeted fix) so it probably fixed this anyway.