Draggable: helper function cannot emulate default behavior

This happens because of this check in

_createHelper

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

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

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? ;-)

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.

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!"

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.

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.

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.

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();
        }

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.

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

Fixes #9446

Changeset: 451dded230c3832a1baacc89333727b25c44cfc7