About the best approach to this is for the jHtmlArea plugin to be updated so that it doesn’t break when other jQuery UI techniques such as dragging and dropping are used.
If I were you, I would add this particular issue that you are having to the jHtmlArea issue tracker, at http://jhtmlarea.codeplex.com/workitem/list/basic
Hmm, I’m not entirely sure it’s a jHtmlArea weakness. It seems more like .clone not doing its job. It’s hard to say though. I’ve never worked on a project like this current one where we use so many plugins and then add feature after feature of our own to the plugins and then start combining the plugins and then adding features to the frankenplugins. It starts to become a very tangled web.
The textarea is contained within the div classed as jHTMLArea, and it’s not the textarea itself that is being dragged. What is being dragged is the list item, which contains that jHTMLArea, which itself contains the textarea element.
What seems to be happening, is that when a parent element of jHTMLArea is being dragged around using jQuery’s draggable and droppable interface, that something goes wrong with iframe that jHtmlArea uses.
While it might be possible for someone else to debug the issue and figure out what’s going on, the person who developed the jHtmlArea plugin is best placed to perform such an investigation, and the end-result is that any successful resolution to the issue will be fed back in to that same plugin to the benefit of all its users too.
Sadly, I do not currently have the time for such investigations, which is why I’m attempting to direct you to where you can find a successful resolution to the issue that you seem to be having with that plugin.
I agree that you’re probably right. I just hope they can be responsive to this.
Trying to see if I can modify my fiddle to capture the data in the IFRAME before the drag and then re-insert it after the drop but IFRAME’s tend to have a mind of their own.
I have to head off now, but it seems that draggable has an iframefix. That’s not going to help with the sortable that you’re using, but someone else seems to have come across a similar issue at http://stackoverflow.com/questions/1595645/jquery-iframefix-on-a-sortable with a potential solution.
Also, jQuery is aware of the iframe problem on sortable objects too - http://bugs.jqueryui.com/ticket/3595
If you manage to come up with an effective solution, then I’m sure that both jQuery and jHtmlArea would love to hear about it.
Thanks.
http://jhtmlarea.codeplex.com/workitem/16028
UPDATE: Oddly the problem does not exist in IE.
Amazingly I am still working on this but I do have some new insight at least. In early testing I was only looking at the IFRAME as it was being dragged and seeing that the content would disappear from it as soon as the drag began. But in more recent testing I saw that the apparently disappearing value was being preserved but within the original row (that hides from view when its clone starts to be dragged). But then when the drop occurs the original row is removed and its clone takes its place. This got me to thinking about grabbing the pertinent value at the beginning of the drag and reading it back into the clone at the end of the drop. The tricky part (for me . . . for the time being . . . ) is identifying the row that has a clone that is being dragged. If I could do it I could grab the pertinent value. But when that row has a clone being drug around there doesn’t seem to be anything unique about it to target that would identify it as the “hiding but cloned but still existing until eventually replaced by its clone” row. More notes are in the comments in my updated jsfiddle:
Have it working a lot better now, only now the successful reload of the data is random: