| Issue 1661: | external drop with revert is inaccurate b/c listening to wrong droppable event | |
| 1 person starred this issue and may be notified of changes. | Back to list |
When using a 'droppable' calendar the 'drop' action appears to be triggering on the draggable's "end" event instead of the droppable's "drop" event. This causes a problem if the draggable is set to 'revert' (animate back to its starting position when dropped). The revert animation counts as part of the drag action, and the draggable's "end" event is not fired until the animation completes. If you drop a draggable on the calendar and then move your mouse while it is animating back to its original position then the calendar will use whatever date your cursor is over at the time when the draggable's animation completes (i.e. something that may be a completely different date from what the draggable was actually dropped). The calendar should trigger on the droppable's "end" event, which triggers immediately when the draggable is released, whether or not the draggable is being used in 'revert' mode. Probably not a severe issue, but I really don't want to have to code around this bug.
Jan 2, 2013
#1
aroth.bi...@gmail.com
Jan 3, 2013
Here's a minimal example that highlights the problem: http://jsfiddle.net/KrZJr/55/
Jan 6, 2013
Here's a quick patch to the 'External Dragging' section (ca. line 656) that works around this issue:
if (options.droppable) {
$(document)
.bind('dragstart', function(ev, ui) {
var _e = ev.target;
var e = $(_e);
if (!e.parents('.fc').length) { // not already inside a calendar
var accept = options.dropAccept;
if ($.isFunction(accept) ? accept.call(_e, e) : e.is(accept)) {
_dragElement = _e;
currentView.dragStart(_dragElement, ev, ui);
}
}
})
.bind('drop', function(ev, ui) { //aroth: change to listen for 'drop' event
if (_dragElement) {
currentView.dragStop(_dragElement, ev, ui);
_dragElement = null;
}
})
$(document.body).droppable({}); //aroth: ensure that the 'drop' event will fire everywhere on the page (note: would be better to just set this up against the calendar's container div, but meh)
}
Aug 21, 2013
thank you
Summary:
external drop with revert is inaccurate b/c listening to wrong droppable event
(was: When in 'droppable' mode the calendar appears to trigger on the wrong event)
Status: Accepted Labels: Type-Bug
Feb 20, 2015
I'm 99% this is fixed with this comment (not yet released): https://github.com/arshaw/fullcalendar/commit/fb24adb2fa53a4a48b2047c6a04e98507f68544c If, possible, could you verify that this fix works?
Status:
Implemented
Feb 21, 2015
This has been released. Thanks! https://github.com/arshaw/fullcalendar/releases/tag/v2.3.0
Status:
Released
|
|
| ► Sign in to add a comment |