As nsISupportsArray is obsolete and isn't supported by the frozen API very well, we should drop it on trunk.
I think we're lacking of frozen alternatives. Using nsIDragService requires passing an nsISupportsArray, even on trunk: http://mxr.mozilla.org/seamonkey/source/widget/public/nsIDragService.idl#66 I think what's more important (but already done for trunk) is that we link our native code against the frozen core libs. At least in js code, we could reasonably well work around interface changes; frozen interfaces would be favourable though.
Daniel, Philipp, what is our status here? Is this FIXED on the trunk?
(In reply to comment #3) > still used: > <http://mxr.mozilla.org/mozilla-central/source/widget/public/nsIDragService.idl#68> Is it possible to avoid this API at all? In Gecko 1.9.1 we can use the API described on https://developer.mozilla.org/En/DragDrop/Drag_and_Drop. But I don't know if this could replace the direct use of 'invokeDragSession'.
While I haven't found out how to set non-string data in the drag session (other than using index-specific methods), the new dnd api seems to allow us to not use nsITransferable, so we could get around using invokeDragSession.
I knew how to do it afterall, just needed some help on understanding the interface docs: http://mxr.mozilla.org/comm-central/source/mozilla/dom/public/idl/events/nsIDOMDataTransfer.idl#225 we can do: let dt = event.dataTransfer; dt.mozSetDataAt("application/x-moz-cal-item", item, 0); dt.setData("text/calendar", item.icalString); dt.setData("text/unicode", item.icalString); in the dragstart event, which will cause the backend code to invoke the drag session. To retrieve the data we can then do the following in the "drop" event. Removing shadows can then be done in dragend handlers as we already do. let item = dt.mozGetDataAt(""application/x-moz-cal-item", 0) .QueryInterface(Ci.calIItemBase); This could greatly simplify drag handling.
Martin, are you still working on this?
(In reply to comment #7) > Martin, are you still working on this? I have some basic D'n'D code which needs some cleanup before I can hand it over to someone to continue the work.
Hey Martin, I'd also take up un-cleaned up code per email if you'd like to share :-)
Martin, any updates? Do you still have any bits of code?
(In reply to Philipp Kewisch [:Fallen] from comment #10) > Martin, any updates? Do you still have any bits of code? Philipp, I found a backup of my code and a copy of the plan on how to rewrite drag'n'drop handling. I will attach the useful pieces Friday night after checking if they could be helpful.
Hey Martin, are those bits still useful?
(In reply to Philipp Kewisch [:Fallen] from comment #12) > Hey Martin, are those bits still useful? Sorry, I missed to get back to you. The code I recovered is not useful (and also not understandable). My plan was to create a jsm for calendar drag'n'drop handling because it takes place in various parts of the user interface but needs consistent handling and processing.
Assignee: mschroeder → philipp
I'm pretty sure bug 1317871 will cover the part of this that blocks bug 394167. :aceman, does that sound right?
I do not see references to nsISupportsArray in the mentioned nsIDragService.idl and nsIDOMDataTransfer.idl files. Eric, maybe you could have put the calendar parts of the patch here.
Flags: needinfo?(acelists) → needinfo?(philipp)
(In reply to :aceman from comment #15) > I do not see references to nsISupportsArray in the mentioned > nsIDragService.idl and nsIDOMDataTransfer.idl files. Eric, maybe you could > have put the calendar parts of the patch here. Okay, I'm going to remove this as a blocker for the nuke nsISupportsArray bugs. I suppose folks might still want to use the modern API, so I'm not going to close/dup this bug.
Severity: normal → enhancement
Priority: -- → P5
Assignee: philipp → nobody
Status: ASSIGNED → NEW
You need to log in before you can comment on or make changes to this bug.