Side navigation
#929 closed bug (wontfix)
Opened February 08, 2007 07:02AM UTC
Closed March 31, 2008 01:29AM UTC
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
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)
Change History (7)
Changed February 08, 2007 07:16AM UTC by comment:1
| resolution: | → fixed |
|---|---|
| status: | new → closed |
Changed February 08, 2007 10:39AM UTC by comment:2
| resolution: | fixed |
|---|---|
| status: | closed → reopened |
Changed February 09, 2007 09:35AM UTC by comment:3
| resolution: | → fixed |
|---|---|
| status: | reopened → closed |
It is not fixed in current release but it is fixed in SVN.
A new release will be out this week
Changed February 12, 2007 03:59AM UTC by comment:4
Thanks :-)
Changed February 12, 2007 04:34AM UTC by comment:5
| resolution: | fixed |
|---|---|
| status: | closed → reopened |
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!
Thanks,
Daniel
Changed February 12, 2007 04:57AM UTC by comment:6
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:
http://paste.pocoo.org/show/957/
-
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.
Changed March 31, 2008 01:29AM UTC by comment:7
| description: | 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. → 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. |
|---|---|
| need: | → Review |
| resolution: | → wontfix |
| status: | reopened → closed |
Interface is no longer supported; consider switching to jQuery UI.
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?
Thanks.