Bug Tracker

Ticket #6446 (closed bug: fixed)

Opened 5 years ago

Last modified 19 months ago

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:
Blocking: Blocked by:

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

comment:1 follow-up: ↓ 17 Changed 5 years ago by edwincheese

comment:2 Changed 5 years ago by jakecigar

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 4 years ago by matas

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 4 years ago by rty

Small improvement to previous for old safari versions compatibility:  http://gist.github.com/gists/434145

comment:5 Changed 4 years ago by rty

Thanks matas for good decision!

comment:6 Changed 4 years ago by ellemme

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 4 years ago by addyosmani

  • Priority set to undecided
  • Status changed from new to open

comment:8 Changed 4 years ago by craig@…

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:

 https://gist.github.com/661844#comments

comment:9 Changed 4 years ago by markedwards

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:10 Changed 4 years ago by snover

  • Milestone 1.4.3 deleted

Resetting milestone to future.

comment:11 Changed 4 years ago by cellartracker

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 4 years ago by john

  • Priority changed from undecided to high
  • Milestone set to 1.next

comment:13 Changed 3 years ago by marcy.sutton@…

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:14 Changed 3 years ago by rwaldron

"test a mobile web-app in Chrome" any suggestions?

comment:15 Changed 2 years ago by jethrolarson

Reduced Test case that shows the bug in IOS 4.0.2 and others.  http://jsbin.com/ofoqoc/5

comment:16 Changed 2 years ago by mikesherov

  • Status changed from open to closed
  • Resolution set to fixed
  • Milestone changed from 1.next to 1.9

This works in latest  http://jsbin.com/ofoqoc/6/edit

comment:17 in reply to: ↑ 1 Changed 19 months ago by anonymous

Replying to edwincheese:

+1 Same issue as reported in JQuery forum:  http://forum.jquery.com/topic/offset-returns-incorrect-values-in-ipad

Note: See TracTickets for help on using tickets.