#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 10 years ago by
Resolution: | → notabug |
---|---|
Status: | new → closed |
comment:2 Changed 10 years ago by
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 simple a bad 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.
comment:3 Changed 10 years ago by
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?
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.