Side navigation
#14157 closed bug (notabug)
Opened July 20, 2013 05:12AM UTC
Closed September 10, 2013 04:52PM UTC
Last modified September 10, 2013 08:25PM UTC
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.
Attachments (0)
Change History (3)
Changed September 10, 2013 04:52PM UTC by comment:1
| resolution: | → notabug |
|---|---|
| status: | new → closed |
Changed September 10, 2013 07:25PM UTC by comment:2
| _comment0: | The box never changes its position with respect to the document. That's easily verifiable by inspecting the element in the JSBin link I provided, with and without the offset applied to its parent container. Element "#c1" doesn't move (relative to the document) when you scroll. \ \ Since offset() is supposed to be relative to the document, and NOT relative to the viewport (scrolling), reporting a negative number for the position is abjectly wrong and a bug. \ \ The negative numbers reflect coordinates relative to the viewport, just like from `getBoundingClientRect()`, so yeah, the box is negatively off the top-left of the *viewport*. But It's still at its original (0,0) position with respect to the document, which is what offset() should be reporting. → 1378842113861961 |
|---|---|
| _comment1: | [Edit: need to correct my comment] → 1378842297568458 |
| _comment2: | 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 parent. \ \ 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. → 1378842312054978 |
| _comment3: | 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. → 1378842356243884 |
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.
Changed September 10, 2013 08:25PM UTC by comment:3
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: autoon 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.