PDA

View Full Version : [DUP] [EXT4.2] Constrain relative/absolute bug



ludoo
11 Apr 2013, 4:57 AM
REQUIRED INFORMATION


Ext version tested:
Ext 4.2.0.663 Ext 4.2.1.744

Browser versions tested against:
Chrome 28.0.1473.0 canary Chrome 26.0.1410.43 m

Description:
Constrain a draggable component into a relative container. If container has an offset, constrain is badly applied on draggable item. Offset seems reported twice. May be a problem with absolute/relative computations.
If left offset is 50px, then draggable item will be constrained at 50px inside its container.

It works with ExtJs4.1.1.
It failed with ExtJs 4.2.x

Steps to reproduce the problem:
Create a div container with a CSS offset
Add a draggable component in it and constrain it to the container.
Move it inside the container.


The result that was expected:
The draggable component can move every where inside the container.


The result that occurs instead:
The draggable item cannot reach left and top border of its container.

Test Case:



<!DOCTYPE HTML><html><head>
<title>Window Constrain</title>
<link rel="stylesheet" href="resources/css/ext-all.css">
<script src="ext/ext-all-dev.js"></script>
<style>
#box{
position:absolute;
left:100px;
top:50px;
width:400px;
height:300px;
border:1px solid blue;
}
</style>

<script type="text/javascript">
Ext.onReady(function () {

Ext.create('Ext.Component', {
left:50,
top:50,
width: 200,
height: 200,
id: 'mybox',
renderTo: 'box',
floating: true,
draggable: true,
constrain: true,
style: {
backgroundColor: '#dedede',
border: '1px solid red'
},
html: '<h1 style="cursor:move">The title2</h1><p>The content2</p>'
});

});
</script>

</head>
<body>
<div id="box"></div>
</body>
</html>





HELPFUL INFORMATION

Screenshot or Video:
43077

Possible fix:
Something changed on floating components with relative/absolute computation. See Component.setPagePosition method : translatePoints(4.1) changed to translateXY(4.2)

Operating System:
Win7

slemmon
11 Apr 2013, 9:26 AM
Thanks for the report! I have opened a bug in our bug tracker.

ludoo
12 Apr 2013, 12:53 AM
After further investigation, it seems that in AbstractComponent.setPosition method, beforeSetPosition returns a wrong position.
This rollback-workaround seems to fix this problem , but I cannot guarantee impacts/regression on anything else.



Ext.define('My.AbstractComponent',{
override:'Ext.AbstractComponent',

//ExtJs4.1 method overrides 4.2
beforeSetPosition: function (x, y, animate) {
var pos, x0;

// decode the position arguments:
if (!x || Ext.isNumber(x)) {
pos = { x: x, y : y, anim: animate };
} else if (Ext.isNumber(x0 = x[0])) { // an array of [x, y]
pos = { x : x0, y : x[1], anim: y };
} else {
pos = { x: x.x, y: x.y, anim: y }; // already an object w/ x & y properties
}

pos.hasX = Ext.isNumber(pos.x);
pos.hasY = Ext.isNumber(pos.y);

// store the position as specified:
this.x = pos.x;
this.y = pos.y;

return (pos.hasX || pos.hasY) ? pos : null;
}

});

skirtle
8 May 2013, 10:18 AM
Thanks @ludoo, you saved me loads of time trying to debug this.

I went with a slightly different patch but along the same lines. I figured it'd be safer to pull a sleight-of-hand rather than completely rolling back the method.


Ext.define('MyApp.AbstractComponent', {
override: 'Ext.AbstractComponent',

beforeSetPosition: function () {
var me = this,
constrain = me.constrain,
constrainHeader = me.constrainHeader,
pos;

me.constrain = false;
me.constrainHeader = false;

pos = me.callParent(arguments);

me.constrain = constrain;
me.constrainHeader = constrainHeader;

return pos;
}
});

I haven't yet established what the constrain code in beforeSetPosition is supposed to do, disabling it doesn't seem to have any negative impact that I've found so far.

cguZZman
12 May 2013, 11:51 AM
thank you guys. you save my day. both solutions works perfect.

thanks again.

nmandya
6 Jun 2013, 7:50 AM
Has this bug been fixed? How can I see the status of the bug filed to track this issue?

extjsuser84
27 Jun 2013, 12:57 AM
I have the same problem switching from ExtJs 4.1.3 to 4.2.1.
My application is composed by a viewport with border layout divided into three parts.
On the left (region west) a collapsible panel, on the bottom (region south) a toolbar and in the center a container in which the windows are opened (children of container). I don't want that when the left panel is collapsed the windows opened in the center container shift left like the panel, so I set the configuration constraint: true to the center container to solve. The windows now do not move longer when the left panel is collapsed but when the panel is expanded the constraint region of the center container is shifted to the left of a number of pixels equal to the width of the left panel and the window items cannot reach left border of its container.
I tried the workaround but it seems not work.