My favorites | Sign in
Project Home Issues
New issue   Search
for
  Advanced search   Search tips   Subscriptions
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
Status:  Released
Owner:  ----
Closed:  Feb 2015


Sign in to add a comment
 
Reported by aroth.bi...@gmail.com, Jan 2, 2013
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
Oops, I mean on the droppable's "drop" event.  Not its "end" event.
Jan 3, 2013
#2 aroth.bi...@gmail.com
Here's a minimal example that highlights the problem:  http://jsfiddle.net/KrZJr/55/
Jan 6, 2013
#3 aroth.bi...@gmail.com
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
Project Member #4 adamrs...@gmail.com
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
Project Member #5 adamrs...@gmail.com
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
Project Member #6 adamrs...@gmail.com
This has been released. Thanks!
https://github.com/arshaw/fullcalendar/releases/tag/v2.3.0
Status: Released
Sign in to add a comment

Powered by Google Project Hosting