Search the Community

Hello, I'm developing a web app that uses polymer to display some custom components and GSAP to drag them around. It appears that there is a conflict between draggable.js and webcomponents.js. Webcomponents.js is used as a polyfill for Firefox/Safari/IE (none Chrome basically) to provide support for the shadowdom and other such things. In Firefox, when I enable polymer on my site, all of my draggable divs become...undraggable. No error is thrown. The draggable events (click, move, etc...) are being thrown but the divs just won't move. However, as soon as I disable polymer (i.e. removing the javascript includes, webcomponents.js specifically), all the divs become draggable again. I looked into the issue and it looks like webcomponents.js wraps all DOM elements within it's own object and this...can have side effects. Here's a link to what I'm talking about: http://webcomponents.org/polyfills/shadow-dom/#known-limitations Looking through draggable.js I figured out that the problem is that some of the matrix calculations are returning NaN as a value and this breaks the transform movement. The specific lines that are causing the calculation error are near the bottom of the _getOffset2DMatrix function. It's these two lines: m[4] = Number(m[4]) + offsetOrigin.x + (offsets.offsetLeft || 0) - parentOffsetOrigin.x - (isRoot ? 0 : parent.scrollLeft) + (offsetParent ? parseInt(_getStyle(offsetParent, "borderLeftWidth"), 10) || 0 : 0); m[5] = Number(m[5]) + offsetOrigin.y + (offsets.offsetTop || 0) - parentOffsetOrigin.y - (isRoot ? 0 : parent.scrollTop) + (offsetParent ? parseInt(_getStyle(offsetParent, "borderTopWidth"), 10) || 0 : 0); And the specific part of both calculations that returns the NaN value is: (isRoot ? 0 : parent.scrollLeft) (isRoot ? 0 : parent.scrollTop) When isRoot is false, for some instances of the calculation (this routine gets called a lot) the "parent.scrollLeft" and "parent.scrollTop" properties are "undefined". Yet, this ONLY happens when webcomponents.js is loaded (which again is needed for Firefox and Safari for Polymer to work). When webcomponents.js is NOT loaded, "parent.scrollLeft" and "parent.scrollTop" return numeric values as intended. The work around a co-worker of mine was able to figure out is to simply "unwrap" the DOM element being passed into the matrix calculations (basically undoing webcomponents.js wrap business). This fixes everything BUT of course means a direct update to draggable.js which isn't ideal for the long term. Here's what we did to fix it for now: _getConcatenatedMatrix = function(e, invert) { e = (typeof unwrap === "function") ? unwrap(e) : e; if (!e || e === window || !e.parentNode) { return [1,0,0,1,0,0]; } .... / We simply added this line at the top of the _getConcatenatedMatrix function. e = (typeof unwrap === "function") ? unwrap(e) : e; The function "unwrap" is defined in webcomponents.js and when executed reverts e to what it is expected to be. Another solution we used that also worked was to update the "isRoot" inline if statement from above to the following: (isRoot ? 0 : (parent.scrollLeft || 0)) (isRoot ? 0 : (parent.scrollTop || 0)) And while this seemed to work and draggability was returned to the divs, we weren't sure if this would actually produce other unknown side effects. Using "unwrap" basically passes through exactly what the code was expecting to receive in the first place if webcomponents.js wasn't loaded, so it seems the most non-bug-producing solution BUT it forces a coupling to webcomponents.js specifically. The other solution, seems to work, but could have unforeseen issues later. And both solutions require updating draggable.js which will make keeping our library up-to-date a hassle. So, my questions to you guys is, have any of you experienced this issue? Did you find a better non-draggable.js modifying solution? Is there any chance draggable.js could be updated to support webcomponent polyfills? Thanks for any feedback, Mariano Martinez III