#6446 closed bug (fixed)
Mobile Safari 4.0.4: $.offset.top() reports wrong position after scroll
Reported by: | matas | Owned by: | |
---|---|---|---|
Priority: | high | Milestone: | 1.9 |
Component: | offset | Version: | 1.4.2 |
Keywords: | iphone, ipad, scroll | Cc: | |
Blocked by: | Blocking: |
Description
demonstration: http://fiddle.jshell.net/G9ZAR/show/light/
source: http://fiddle.jshell.net/G9ZAR
click on the first link, click on the second.
Safari 4.0.5 shows offset().top 390 Mobile Safari 4.0.4 (on iPad) shows offset().top 780
it seems that after vertical scroll, the scrollTop get's added to the actual position.
Change History (17)
comment:1 follow-up: 17 Changed 13 years ago by
comment:2 Changed 13 years ago by
my workaround is
$.browser.mobileSafari = /webkit.*mobile/i.test(navigator.userAgent) $.fn.cssKluge=function(css){
if ($.browser.mobileSafari){
css.top-=window.scrollY css.left-=window.scrollX
} return this.css(css)
}
comment:3 Changed 13 years ago by
thanks jake,
here's my (dirty) take on the override: http://gist.github.com/431639
what would be a clean solution? probably adding an absolutely positioned element to an iframe, scrolling it and then testing for the offset === position
comment:4 Changed 13 years ago by
Small improvement to previous for old safari versions compatibility: http://gist.github.com/gists/434145
comment:6 Changed 13 years ago by
rty I've added an extra test vs iOS version since the bug occurs only on 3.2-4.0.x, 4.1 is not affected. Feel free to add the following test condition to your snipplet:
/; CPU.*OS (?:3_2|4_0)/i.test(navigator.userAgent)
comment:7 Changed 13 years ago by
Priority: | → undecided |
---|---|
Status: | new → open |
comment:8 Changed 13 years ago by
Just thought I'd add my own little detection JS to the mix. It's a lot smaller than others but relies completely on the user agent string:
comment:9 Changed 13 years ago by
I've found that calculating the offset with straight javascript seems to work. Test page:
http://mark.antsclimbtree.com/files/jquery.ipad-test.php
Clicking the yellow square shows the top and left as calculated by jQuery as well as straight javascript. They should always be the same, but on iOS <4.1 they are not if you scroll anywhere.
So, is this indeed simply a bug in jQuery? Anyway, a workaround that doesn't involve browser detection might be to not use jQuery to calculate the top and left.
comment:11 Changed 13 years ago by
For all those using the workaround function hack, you *might* want to test result for null before you start subtracting. (I had some poorly behaved code that happens to call offset and get a null. The workaround function exploded in the same scenario...)
comment:12 Changed 12 years ago by
Milestone: | → 1.next |
---|---|
Priority: | undecided → high |
comment:13 Changed 12 years ago by
This actually occurs on the desktop as well... test a mobile web-app in Chrome by scrolling and then clicking on your target -- gets the same result as mobile safari.
comment:15 Changed 11 years ago by
Reduced Test case that shows the bug in IOS 4.0.2 and others. http://jsbin.com/ofoqoc/5
comment:16 Changed 11 years ago by
Milestone: | 1.next → 1.9 |
---|---|
Resolution: | → fixed |
Status: | open → closed |
This works in latest http://jsbin.com/ofoqoc/6/edit
comment:17 Changed 10 years ago by
Replying to edwincheese:
+1 Same issue as reported in JQuery forum: http://forum.jquery.com/topic/offset-returns-incorrect-values-in-ipad
+1 Same issue as reported in JQuery forum: http://forum.jquery.com/topic/offset-returns-incorrect-values-in-ipad