This project is archived and is in readonly mode.

#952 ✓resolved
inta

getPosition returns wrong y coordinate for select element

Reported by inta | July 27th, 2010 @ 12:07 PM | in 1.3.1 (closed)

If you have got a select element with scrollbar, getPosition returns not the correct accumulated position of the select element if you scrolled down.

I created a small showcase:
http://mootools.net/shell/DLv7y/

For example click on "5", you get 10 as vertical position for the select element. Now scroll down a bit and click on "5" again, you will get something smaller than 10 although the select didn't change its position.

"offsetTop" would still return the right value (in this case).

At least with Firefox this problem is reproducable.

Comments and changes to this ticket

  • inta

    inta August 23rd, 2010 @ 10:16 AM

    • Assigned user set to “Valerio”

    I don't know whos responsible for this, but as nobody recognised this so far, i'll give the ticket to Valerio.

  • Christoph Pojer

    Christoph Pojer September 3rd, 2010 @ 11:09 AM

    • State changed from “new” to “invalid”

    I am unable to reproduce this in Chrome, Firefox or Safari.

  • inta

    inta September 3rd, 2010 @ 11:43 AM

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

    In your test the output digit did not change and was always positive?
    I can reproduce the error in Firefox 3.6 up to the current nightly. With Chromium its not reproducible.

  • Christoph Pojer

    Christoph Pojer September 3rd, 2010 @ 11:55 AM

    Yes. Tested on Mac OS. The number is different in some browsers, but it stays the same. Can you try wrapping the select element within a div and tell me if the output stays stable?

  • inta

    inta September 7th, 2010 @ 06:31 AM

    Ok, please try it on a Windows or Linux system, the problem is reproducible there. I will try it later on Mac OS.

    Wrap the select in a div an get the position of that div element? Seriously? Thats no solution, thats a workaround.

  • Mogzor

    Mogzor September 7th, 2010 @ 08:22 AM

    I got the bug too.
    Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8
    Win XP

  • inta

    inta September 7th, 2010 @ 05:10 PM

    I can reproduce it even on Mac OS X and Firefox 3.6. Are you sure, you scrolled down the select before clicking (again)? If you do not scroll, the position is correct.

  • gonchuki

    gonchuki September 7th, 2010 @ 07:06 PM

    I can also reproduce it on Fx 3.6.8 on WinXP.

    So far I could confirm that getScrolls is returning the actual scrolled amount of the select element on Firefox but it's fixed at 0 on Chrome 6. Digging down I can see both getScroll and getScrolls simply return the element.scrollTop value.

    Now, I'm not sure how scrollTop is supposed to work on the select element, but seems like what Firefox does is actually correct.
    I did an alternate test using jQuery as they have a totally different approach to retrieving the scroll position and the result is the same: Firefox exposes the scrolled amount, but Chrome and IE8 stay at 0. http://www.jsfiddle.net/mH8wW/

    Maybe we need an insight on what's the expected result before deciding if it is something that Moo needs to normalize? Is there a typical use case where this browser inconsistency is exposed? (maybe it's me but I can't see getting this value being something useful)

  • gonchuki

    gonchuki September 7th, 2010 @ 07:12 PM

    oh wait, silly me. there's actually usefulness in getPosition. I got my head so wrapped around the scrollTop issue that I forgot this ticket was about getPosition.

    I re-edited the above jQuery snippet to use .position() and they are returning the correct value when the element is scrolled: http://www.jsfiddle.net/ftJU2/

    definitely seems like something we need to fix in Moo (I will probably investigate a bit more later).

  • Fábio M. Costa

    Fábio M. Costa September 7th, 2010 @ 08:49 PM

    • Milestone set to 1.3.1
    • State changed from “invalid” to “open”
    • Milestone order changed from “784” to “0”

    Yes i can see the problem happening. Thanks for the report @inta.
    Thanks for looking into it @gonchuki.

  • Christoph Pojer

    Christoph Pojer September 7th, 2010 @ 08:51 PM

    • Milestone changed from 1.3.1 to 1.3.0 rc2
    • State changed from “open” to “invalid”
    • Milestone order changed from “2” to “0”

    @gonchuki you wanna look into it and fix it for 1.3?

  • Christoph Pojer

    Christoph Pojer September 7th, 2010 @ 08:57 PM

    • State changed from “invalid” to “open”
  • Christoph Pojer

    Christoph Pojer September 8th, 2010 @ 11:35 AM

    • Milestone changed from 1.3.0 rc2 to 1.3.1
    • Milestone order changed from “1” to “0”
  • inta

    inta September 8th, 2010 @ 12:52 PM

    Is it a matter of time, why this is dedicated to 1.3.1? I only used mootools for projects so far, but if you need help, i would take a look at this.

  • gonchuki

    gonchuki September 8th, 2010 @ 02:20 PM

    @cpojer
    I will take a look and see what I can find. Any ideas why are we using scrollTop as part of the getPosition method? so far the MDC {1} and MSDN {2} tell me that not only scrollTop is not a standard API, but also that IE always gave zero as the scrolled position for a select element (and probably other browsers except Firefox are just mimicking what they do).

    {1} https://developer.mozilla.org/en/DOM/element.scrollTop
    {2} http://msdn.microsoft.com/en-us/library/ms534618(VS.85).aspx

  • Christoph Pojer

    Christoph Pojer September 8th, 2010 @ 02:21 PM

    Dimensions is a hack :)

    @gonchuki if you can find a fix today (or tomorrow) I'll add it for 1.3, otherwise it goes into 1.3.1. thanks for looking into it.

  • gonchuki

    gonchuki September 9th, 2010 @ 08:30 AM

    so here's the thing: I cross tested and analyzed every other framework that I could absorb in a day and the conclusion is that every framework measurement functions are a hack.

    Now for what is the MooTools domain, seems that we are fetching the scrolled amount on the wrong element. I made a simple patch and verified against jQuery {1}, Prototype {2} and Dojo {3} and looks like my patch is actually fixing the issue we had; both avoiding the select element inconsistency, and returning the correct position for elements with overflow that are currently scrolled. You can compare against the MooTools example {4} to see where the different measurement is. (as a sidenote, our code looks tons of times better than the others, I really don't think we are doing it that bad ;) ).

    pull from here: http://github.com/gonchuki/mootools-core/commit/12c6e9506295793e227...

    refs: (pardon my puny testing code, 4am in the morning gets me down to this).
    {1} http://jsfiddle.net/992UN/2/
    {2} http://jsfiddle.net/vtuAC/2/
    {3} http://jsfiddle.net/ZcpCn/
    {4} http://jsfiddle.net/yQgQs/

  • gonchuki

    gonchuki September 9th, 2010 @ 03:16 PM

    Stop the press! :)

    Taking some breeze in the morning refreshed my mind, and then I remembered that #637 was about correcting an issue with getScrolls.
    Turns out that the bug reported in #637 was real, and that my fix was only a placebo for #952.

    The real deal: getOffsets was overcompensating the error in getScrolls by substracting the element's own scrolled amount.

    So then I just made the new fix, re-tested all again and everything seems and looks better now :)

    TL;DR pull here: http://github.com/gonchuki/mootools-core/tree/952_and_637_fix

  • Christoph Pojer

    Christoph Pojer September 9th, 2010 @ 11:13 PM

    • State changed from “open” to “resolved”

    Hey man. Thank you so much for looking into this and #615 :)

Create your profile

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

Shared Ticket Bins

Referenced by

Pages