Question

I have a wierd issue with jQuery which I’ve never seen before.

I have a bit of script to calculate the position().top value of an element which is always on the page. It’s an li inside a ul inside a div.

The works every time I post a fresh request, normally returns 300.
However if I then hit ctrl-r and redo the request, the same code for the same page returns 0 for position().top. Refreshing again sees it work.

This happens consistently, every 2nd page refresh. However each fresh page request (with changed params or just resubmitting the form) seems to work fine. I haven’t witnessed this strange failure cycle go out of sequence.

caveats

Now on to the caveats (and a bit of code):
I’m using the easing and zebra_datepicker plugins, and have written my own vertical slider plugin which contains the code that consistently fails to get the right position of my element.

So I’m not expecting this to be a common occurrence, nor can I post the full source so instead I’m posting a snippet with the odd code for context more than anything else:

// inside each loop for slider parent elements
// $(this) references the slider container, i.e <div>
var slideTo = $(this).find('.slideTo').position().top; //300 or 0

This code is in the plugin itself, which is then called in a $(window).load() event.

The way this behaves makes me think it’s some kind of race condition but I can’t find anything in my code that does things in the wrong sequence or runs more than once, and believe me I’ve filled it to the gunnels with debug.

tl;dr

So my question is this: are there any circumstances where jQuery.position().top will return 0, given that the targeted element exists and has loaded by the time the call is made?

Are there any silly mistakes I could have made to make this happen; could it be due to invalid markup or maybe something to do with the fact that the element is an li?

Answer 1

Turns out this wasn’t always returning zero as I had thought.

What was happening is that when I modified the scrollTop of my parent element, then refreshed the page, Firefox remembered the scrollTop value on the refresh – so my calculation came back as zero then because with the remembered scrollTop value, the position of that element was zero.

So this behaviour was not buggy at all and position() was doing exactly what it should.

I got around this problem by setting the scrollTop of my elements to zero before running these calculations, which stopped Firefox’s remembered value from breaking things for me.