This project is archived and is in readonly mode.

#610 ✓wontfix
orangesunshine

getPosition() / getCoordinates() fixed positioning bug

Reported by orangesunshine | March 5th, 2009 @ 12:36 AM | in 1.3.0 rc2 (closed)

http://dpaste.com/6500/

when you scroll down you can no longer sort your stuff.

This is a result of an issue in the checkAgainst function in the Drag.Move class. It compares the mouse position to the position of the element.

The issue is that if you scroll down getCoordinates does not account for that when calculating the 'real' position of the element ... if it or one of its containers is fixed it should be. so .. you'll have to check all the way back up to the body to see if one of the container elements has a fixed position.

perhaps it's an issue with the getScrolls() function .. or somewhere further up the chain.

adjusting the response of el = el.getCoordinates(); ... fixes the error in my use case. however, it needs to check if any of the parents are fixed ... as it shouldnt' make these adjustments when not fixed.

    scrolls = Window.getScroll();

    el.top = el.top + scrolls.y;
    el.bottom = el.bottom + scrolls.y;

Comments and changes to this ticket

  • orangesunshine

    orangesunshine March 5th, 2009 @ 08:20 PM

    here's a quick fix ... not sure if it needs to check if it's fixed in every check against call ... but it works for anyone who needs this asap. This is a mod to the Drag.Move class ...

    isFixed: function(element){
    fixed = false;
    while(element.id && fixed == false){
        if (element.getStyle('position')=='fixed') fixed = true;
        else element = element.offsetParent;
    }
    return fixed
    },
    
    checkAgainst: function(el){
        var now = this.mouse.now;
        var fixed = this.isFixed(el);
        el = el.getCoordinates();
        if (fixed){
            scrolls = Window.getScroll();
    
            el.top = el.top + scrolls.y;
            el.bottom = el.bottom + scrolls.y;
        }
        return (now.x > el.left && now.x < el.right && now.y < el.bottom && now.y > el.top);
    },
    
    
  • fakedarren

    fakedarren February 8th, 2010 @ 07:26 PM

    • State changed from “new” to “hold”
    • Assigned user set to “fakedarren”
    • Milestone changed from 2.0 to 1.3.0 rc2

    Stock answer, same as all the others - putting on hold, I assume this was fixed. If OP can provide a mooshell that shows the issue, so much the better, if not, will investigate further

  • Christoph Pojer

    Christoph Pojer November 9th, 2010 @ 07:25 PM

    • State changed from “hold” to “wontfix”
    • Milestone order changed from “0” to “0”
  • 3n

    3n May 17th, 2011 @ 03:29 AM

    • Assigned user changed from “fakedarren” to “Christoph Pojer”

    So the issue I'm seeing, and why I feel this should be reopened, is the different behavior between browsers with getBoundingClientRect and those without. Currently, if you get the position of an element on modern browser and also an older browser, the two values will not match if the user has scrolled. This is a problem that affects lots of UI plugins (e.g. tooltips).

    I initially wrote the code that uses getBoundingClientRect, and I added a check for if the element ('this') was fixed, and add the window scroll to the position if it is not. This is necessary since getBoundingClientRect measures distance from viewport and doesn't take scrolls into account. For non-fixed elements we want to add the scrolls back, to be consistent with the code run in older browsers. This works when the element itself is fixed, but not if the element simply lives inside a fixed container. I feel we should add an isFixed() method (that traverses up) and use it instead of the simple check for fixed on the current element.

    A patch has been attached.

    P.S. Another solution would be to stop treating fixed and non-fixed elements differently. Essentially, think of it as "how many pixels from the top or left would I need to position an absolute element to be on top of 'this' element (tooltips). This would mean that as you scrolled, the return value of a call to fixedPosElem.getTop() would change, but a call to nonFixedPosElem.getTop() would not. To do this we'd need to do a few things:

    1. Remove all the isFixed code from the top (getBoundingClientRect) portion of getOffsets. Add the scrolls to everything.
    2. Modify the code below (for old browsers) to add the scrolls to fixed elems.
    3. Update plugins and such in More if they were relying on this behavior.

    (This second choice is clearly pretty drastic, but makes a lot of sense in the long-term as non getBoundingClientRect browsers go away.)

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

Shared Ticket Bins

People watching this ticket

Attachments

Pages