Bug Tracker

Opened 17 years ago

Closed 16 years ago

#929 closed bug (wontfix)

DraggableDestroy does not restore standard browser click/drag reactions

Reported by: KDan on freenode #jQ Owned by: stefan
Priority: major Milestone: 1.1.3
Component: interface Version: 1.1a
Keywords: Cc:
Blocked by: Blocking:

Description (last modified by scott.gonzal)

Detected in interface 1.1.2, latest version downloaded 08/02/2007.

When a previously draggable item is marked is DraggableDestroy()ed, it correctly loses its drag'n'drop functionality, but does not regain standard browser functionality, such as the ability to select text.


Possible cause:

I believe this is due to the fact that the jQuery.iDrag.build() method overrides a large number of browser events (onselectstart, ondragstart, ondrag...), but the jQuery.iDrag.destroy() method just unbinds the iDrag init and resets a couple of variables, and does not restore the browser events.


Desired situation:

I believe that in this situation, the Draggables plugin should restore standard browser functionality (e.g. selection) when the Draggable is destroyed.


Possible solution:

Alter iDrag.destroy() to ensure it restores browser events.


Why this is important:

Although this does not affect the operation of the Draggable plugin on its own, it does affect its interaction with other plugins, and with more basic browser functions. Essentially, anything that is draggable cannot have any other useful functionality that relies on the browser's drag and drop. The example I'm hitting is the attempt to have an Editable field inside a draggable item (drag and drop items between folders, click on their name to rename them, like Explorer). In this case, the Editable plugin works fine and creates the input field, but the input field itself is broken - visual feedback of text selection is missing, and it's not possible to select the text inside the field with the mouse.


How to contact me for more info:

I can be found on #jQuery on freenode under name KDan in very early UK morning (3am->6am) and some evenings, or emailed at: daniel / at / tenner / dot / org /

I'll check this ticket every few days to see if more information is requested, too.

Attachments (4)

test.html (4.7 KB) - added by KDan 17 years ago.
Test file for Bug #929
test.2.html (4.7 KB) - added by KDan 17 years ago.
Test file for Bug #929
test.3.html (4.7 KB) - added by KDan 17 years ago.
A test file for Bug #929
test.4.html (4.7 KB) - added by KDan 17 years ago.
Test file for #929

Download all attachments as: .zip

Change History (11)

comment:1 Changed 17 years ago by stefan

Resolution: fixed
Status: newclosed

comment:2 Changed 17 years ago by KDan

Resolution: fixed
Status: closedreopened

Hello, me again, not sure why this has been marked as fixed. It is not fixed in the current release. If it has been fixed, when is it due to be released, and would it be possible to gain access to the fix early?


comment:3 Changed 17 years ago by stefan

Resolution: fixed
Status: reopenedclosed

It is not fixed in current release but it is fixed in SVN.

A new release will be out this week

comment:4 Changed 17 years ago by KDan

Thanks :-)

Changed 17 years ago by KDan

Attachment: test.html added

Test file for Bug #929

comment:5 Changed 17 years ago by KDan

Resolution: fixed
Status: closedreopened

Hi Stefan,

I've downloaded the CVS fix and tested it on my (currently internal-only) page, and I'm afraid it didn't work. So I created a test page, to illustrate the problem. I'm trying to attach it to this bug, and if I don't manage I'll post it up externally instead. Since you already implemented my proposed fix it may be that the actual fix is more complicated than I thought.

Will post again once I've managed to attach a file!



Changed 17 years ago by KDan

Attachment: test.2.html added

Test file for Bug #929

Changed 17 years ago by KDan

Attachment: test.3.html added

A test file for Bug #929

Changed 17 years ago by KDan

Attachment: test.4.html added

Test file for #929

comment:6 Changed 17 years ago by anonymous

For some reason trying to attach a file says:

Invalid Attachment

Attachment bugs/bug/929: test.4.html does not exist.


So instead I've pasted it here:



Description of the linked file:

To make it work, make sure jQuery files are in the correct subdirectory (from headers) - or modify the script tags to point to the correct place. Only plugin used other than jQuery and iface is a simple modified version of one of the editable plugins, included inline.

Basically all that the code does is make the lists Sortable, and then make the list items editable. The editable plugin is written so that you can provide a callin function which is called at the beginning. In that callin I call DraggableDestroy in hope of restoring normal browser functionality on the field before it is edited. I do not call SortableAddItem afterwards because that is not needed to illustrate the issue.

The issue is that once you click on the item and it loses its Draggable abilities, becoming an input field, it still doesn't recover standard functionality like being able to select text inside the input field. This can be seen by clicking on one of the items, then pressing shift and the left cursor key a few times, then typing something - the selection works, it just doesn't display visual feedback.

This can also be seen after you click off the editable field - since the Draggable aspect is not restored, if you then attempt to click and drag the item it won't drag (expected), but it also won't allow you to select the text (not expected).

The expected behaviour would be for DraggableDestroy to restore whatever selection/highlighting functionality existed before the item became a Draggable.

Please let me know if I can further clarify the issue.

comment:7 Changed 16 years ago by scott.gonzal

Description: modified (diff)
need: Review
Resolution: wontfix
Status: reopenedclosed

Interface is no longer supported; consider switching to jQuery UI.

Note: See TracTickets for help on using tickets.