View Full Version : Draggable - revert: false prevents intersections working

1 Aug 2011, 1:41 PM
Sencha Touch version tested:


only default ext-all.css

Platform tested against:

iOS 4.3.3
Safari 5.1
Chrome (OSX) 15.0.839.0


If an Ext.util.Draggable object is created with revert set to false, and then the object is moved to a position on the screen and let go, any future intersection detection fails to occur at the correct location.

See http://www.sencha.com/forum/showthread.php?142350-Draggable-region-amp-offset-issue for original post of problem.

Test Case:

Using the dragdrop example code from the distribution, in index.js change revert to false as per the following snippet.

// Setup the Sencha Touch app.
icon: 'icon.png',
tabletStartupScreen: 'tablet_startup.png',
phoneStartupScreen: 'phone_startup.png',
glossOnIcon: false,
onReady: function(){
// Create a new draggable for the div with an
// id of 'draggable'
new Ext.util.Draggable('draggable', {
revert: false

Steps to reproduce the problem:

After making the change described above, open the web page and move the left Draggable block a few inches to the right.
Now drag it back fully into the Droppable area.

The result that was expected:

The Droppable area should go dark green, indicating that the Draggable is contained within it.

The result that occurs instead:

The Droppable area stays light green indicating that the dropenter event did not fire.

Debugging already done:

I edited the source code to log draggable.region.left and draggable.region.top for the Draggable as it moves. The co-ordinates are as expected during the drag operation and after letting go of the Draggable. However, once you start to drag it again, the co-ordinates jump up/down unexpectedly. It turns out that the delta is equal to the Draggable.offset values. Because the draggable.region is now offset from where it should be, when it is compared with droppable.region (in the Ext.util.Droppable.isDragOver private method), the intersection occurs at the wrong location.

Possible fix:

not provided

1 Aug 2011, 3:10 PM
The Sencha version should say 1.1.0.

4 Aug 2011, 1:05 PM
Possible fix:

Intersection detection relies on Draggable.region intersecting with (or, optionally, being contained by) Droppable.region
Draggable.region is updated on each move of the object by Draggable's setOffset method. In this method, this.region is updated by adding the current values of offset to this.initialRegion. The value of offset is the vector of the object now from it's initial location. So, if this.initialRegion represents where the object was initially placed, as the name would suggest, then this would be fine.
But... this.initialRegion is getting updated with every call to updateBoundary, as shown below starting at line 24169 of sencha-touch-debug-w-comments.js:

this.initialRegion = this.region = new Ext.util.Region(
elXY[1], elXY[0] + this.elBox.width, elXY[1] + this.elBox.height, elXY[0]

So, if we modify the code so that this.initialRegion is only updated on the very first time this code is run, like so:

this.region = new Ext.util.Region(
elXY[1], elXY[0] + this.elBox.width, elXY[1] + this.elBox.height, elXY[0]

if (!this.skipUpdate) {

then this.initialRegion continues to represent the initial region, and the Draggable's region property remains accurate.
Incidentally, this problem had nothing to do with revert being set to false. It just presented it's self when that was the case.

15 Aug 2011, 5:17 AM
Bumped, after 2 weeks, in the hope that Sencha will log this...

19 Sep 2011, 6:48 AM

I had exactly the same issue with Draggable component and Region, after moving programmatically the Draggable item with the setOffset method. With Sencha Touch 1.1.0.
The fix provided by Powderhound works fine. Thank you for this !

So.... *bump*. Hope this fix will be included in the next Sencha Touch release !

18 Oct 2011, 9:02 AM
I spent a few hours scratching my head over strange drag/drop behavior before I became convinced this was a bug in Sencha Touch and found this thread. BTW I'm using version 1.1.0. The bug fix works like a charm.

Also -- I just downloaded 1.1.1 and it has the same problem. And the same fix works.