I have posted a fix in lighthouse for this bug: https://mootools.lighthouseapp.com/projects/2706/tickets/662-patch-to-enable-fixed-position-droppables-for-dragmove
On Jun 27, 8:39 am, Dimitar Christoff <[email protected]> wrote: > mootools 1.2.1 - 1.2.3, all happens. > > working on a little form > here:http://www.cleaning-4u.co.uk/rug_cleaning_Bournemouth_776.html > > click on the 'get your free quote' - a modalBox comes up (also movable) > and then there's a widget 'prove you are human' > > within this widget there are 'icons' that need to be drag 'n dropped > into the target droppable. > > it all works fine in Firefox but in IE, as soon as you create the > drag.move object, the icon that's meant to be dragged repositions itself > at the top-left of the parent window... > > I think the problem may be with the .getPosition of element.offsetParent > called in mootools-more, line 970 of drag.move: > > if ([this.element.getStyle('left'), > this.element.getStyle('top')].contains('auto')) > this.element.position(this.element.getPosition(this.element.offsetParent)); > > Essentially, this.element.getPosition(this.element.offsetParent).x comes > back as '5' in IE7 and 525 in FF. > > .offsetParent is the same id for both: > > C.log(this.element.offsetParent.id); -> mOOdalBox > > but for FF / IE results go: > C.log(this.element.getPosition(this.element.offsetParent).x); 525 / 5 > C.log(this.element.getPosition(this.element.offsetParent).y); 309 / 1 > > I am going to leave the C.log (which would use alert() if no console > available) for now... > > Is this an error in .getPosition(relative) or is it passing it the wrong > relative? > > any help appreciated - I can easily get rid of the whole check but now I > would rather it worked instead :) > > Thanks. > -- > [email protected] |http://fragged.org/
