Skip to main content

Search and Top Navigation

#9446 closed bug (fixed)

Opened July 22, 2013 06:28PM UTC

Closed August 19, 2014 07:24PM UTC

Last modified August 20, 2014 02:02AM UTC

Draggable: helper function cannot emulate default behavior

Reported by: Bob Stein, VisiBone Owned by: Bob Stein, VisiBone
Priority: minor Milestone: 1.11.2
Component: ui.draggable Version: 1.10.3
Keywords: Cc:
Blocked by: Blocking:

In the .draggable() widget, the "helper" object is what visually moves around the screen while dragging. The default behavior has the draggable element itself serve as the helper object.

When specifying a helper function, I sometimes want to mimic this default condition, where the helper is the draggable. But returning the draggable element (as a jQuery object) doesn't do this, that just makes the helper invisible.

In this jsfiddle demo, the first img drags, but the second doesn't seem to budge. The dragging is going on however, a stop function would get called.

Using jQuery 1.10.2, UI 1.10.3 in my application and seeing this. The jsfiddle demo uses 1.9.1/1.9.2

Attachments (0)
Change History (12)

Changed July 23, 2013 02:34AM UTC by tj.vantoll comment:1

status: newopen
summary: .draggable() helper function, cannot emulate default behaviorDraggable: helper function cannot emulate default behavior

This happens because of this check in


if(helper[0] !== this.element[0] && !(/(fixed|absolute)/).test(helper.css("position"))) {
	helper.css("position", "absolute");

Because the helper is the element, it is never set to

position: absolute
so dragging it does not work. This seems like a valid use case.

Changed August 07, 2013 12:54PM UTC by scottgonzalez comment:2

owner: → Bob Stein, VisiBone
status: openpending

This seems like an edge case. Can you explain why you'd be using a function to return the original element?

Changed August 07, 2013 02:44PM UTC by Bob Stein, VisiBone comment:3

status: pendingnew

Sure! Maybe it only seems like a pointlessly simple edge case because I was trying to make a very simple example to demonstrate the bug.

I'm trying to visually simulate a "stack" of identical objects. Think of a pad of post-it notes. When the "stack" contains 2 or more, I want to clone the image as I drag the "top" object off of the "stack". When the "stack" only has 1 left, I want to drag the object itself, leaving nothing behind. Akin to moving the last post-it note in a pad. So within the helper-function, I want to do some logic, and then decide whether to return $(this) or $(this).clone(). The latter works. The former doesn't. So I just wanted to demonstrate that.

Seem less edgy now? ;-)

Changed August 07, 2013 06:01PM UTC by scottgonzalez comment:4

status: newopen

Still seems like an edge case to me. You could just set the helper option appropriately ahead of time (you know when the stack gets to one). I'll leave this open, but it's unlikely to be fixed prior to the interaction rewrite unless someone send a pull request with tests.

Changed August 07, 2013 06:41PM UTC by Bob Stein, VisiBone comment:5

Thanks for the workaround Scott, already doing something like that. But the function remains broken. Doesn't it strike you as a let-down when the function-flavor of a parameter does less than the string-flavor?

I'm wondering how you understand the term "edge case". I thought it meant an extreme, like a gigabyte image, or dragging at relativistic speeds. We're talking about the ''default'' behavior of a draggable's helper, and the function can't even ''do'' that. It's like a Swiss Army knife that has every tool but a knife. Or a calculator that can add any number but zero. "Why would anyone have a legitimate need to add zero to a number? You already have your answer right there!"

Changed August 07, 2013 07:01PM UTC by scottgonzalez comment:6

Please, no analogies. They're almost always fatally flawed. Like having a swiss army knife and being bummed about the fact that it doesn't have a blade while you're holding a perfectly sharp knife in your other hand.

The helper option exists to generate a helper. So, yes, returning the original element and claiming that it's the helper, when in fact you do not want a helper at all, is an edge case. I would venture a guess that this behavior has existed for several years; if this is just now being reported then it's a good assumption that this is almost never attempted, which also indicates that this is an edge case.

Changed August 07, 2013 07:35PM UTC by Bob Stein, VisiBone comment:7

That's okay, the calculator analogy was better. The default condition isn't that there is no helper, it's that the helper is the original object. This form is in the documentation:

        helper: "original"

(Just verified that it works.) A helper function should be capable of degrading gracefully and making the default condition happen.

Changed August 07, 2013 07:40PM UTC by scottgonzalez comment:8

No, the default condition is that there is no helper. The fact that it uses a string "original" is just another example of the terrible API that draggable has. The upcoming API does not accept string values.

Changed August 07, 2013 07:56PM UTC by Bob Stein, VisiBone comment:9

No strings? You're saying helper: "clone" is going away? That means my workaround is going to break. Will the following continue to work?

        helper: function(){
            return $(this).clone();

Changed August 07, 2013 08:05PM UTC by scottgonzalez comment:10

helper: true will replace helper: "clone" (The user should only indicate that they want a helper, not that there is a specific implementation of cloning that they care about). The clone function will also continue to work.

Changed August 19, 2014 07:24PM UTC by Mike Sherov comment:11

resolution: → fixed
status: openclosed

Draggable: Ensure helper is positioned even if its the element itself

Fixes #9446

Changeset: 451dded230c3832a1baacc89333727b25c44cfc7

Changed August 20, 2014 02:02AM UTC by mikesherov comment:12

milestone: none1.11.2