Bug Tracker

Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#14157 closed bug (notabug)

a breaking case for offset()

Reported by: getify Owned by:
Priority: undecided Milestone: None
Component: unfiled Version: 1.10.2
Keywords: Cc:
Blocked by: Blocking:

Description

I discovered, by accident, a somewhat unusual case (which happened quite naturally in my app, of course!) where the offset() function is incorrectly reporting values. Specifically it's including scroll positioning in the values in a way that it shouldn't.

See this jsbin link: http://jsbin.com/unuyef/1/

If you click on the green area while the frame is scrolled the top and left, you get (0,0) like you expect. But once you start to scroll the frame either down or right, and click the green box, the offset top and left become more and more negative.

If you look at the CSS part, and remove either the overflow:auto or the height:100% that's set on the #p1 element, then offset() starts working as expected, meaning it always returns (0,0) regardless of scroll position.

I'm not sure WHY that's the case, just that's what I've narrowed it down to.

I've tested this in FF24, Chrome 30, and Saf 6.0.5, all on mac.


BTW, I found a number of other bugs which *could* make my report a duplicate, but none of them showed the same cause/symptom combination I'm seeing and showing in my test case, so I figured if nothing else, my test case is helpful extra info.

It's quite possible there's an underlying bug common across them and mine is just another variation of those other reports.

Change History (3)

comment:1 Changed 6 years ago by timmywil

Resolution: notabug
Status: newclosed

This actually seems accurate. The overflow: auto on the parent changes the position of its child (rather than scrolling the document). Since .offset() is relative to the document, the negative numbers are accurately representing the child's position relative to the document.

comment:2 Changed 6 years ago by getify

I now understand what you were saying, that it was the #p1 element that was scrolling, and not the document itself, which would in fact change the child's position relative to the document.

This is simply a poor test case on my part to illustrate the real problem I was having in my app. I will go back to the app and try to extract a better test case that illustrates the bug I was seeing. Sorry about the confusion.

Last edited 6 years ago by getify (previous) (diff)

comment:3 Changed 6 years ago by timmywil

It's relative to the viewport and the document. Thinking about where the element is (though I can't really see the top left corner), the document starts at 0 and the element starts off the page. How is it still at 0,0 relative to the document?

Note: See TracTickets for help on using tickets.