Remove webkitConvertPointFromNodeToPage #796

wants to merge 2 commits into


None yet

6 participants


Yeah, i know, i know, you guys voted on it. But hear me out for a minute, from ticket description –

"For older versions of Safari (or older mobile safari) it seems simpler to calculate offset using window.webkitConvertPointFromNodeToPage()."

In what browsers, exactly, we have webkitConvertPointFromNodeToPage and do not have getBoundingClientRect? For desktop browsers it's simple – for Safari, support for webkitConvertPointFromNodeToPage begins from Safari 4, just like for getBoundingClientRect, Chrome always had it.

Mobile browsers? There is no way to reliable know if all mobile webkit-based browsers lists here is have webkitConvertPointFromNodeToPage and do not have getBoundingClientRect. Only way to know that, is to check lowest versions of them all –

  • Apple iOS 3.2
  • Android 2.1
  • Blackberry 6
  • Blackberry Playbook 1
  • Palm WebOS 1.4
  • Meego 1.2
  • Dolphin 3
  • Kindle Fire

And i did – they all have getBoundingClientRect, which means webkitConvertPointFromNodeToPage code path will never be chosen, which means webkitConvertPointFromNodeToPage is dead code and should be removed.

cc @mikesherov


@rwldrn, hey, I already did that :)


Sorry, I missed that. (it's a habit now, for all things box related)


Yeah, I'm with you on this one @orkel. I kept it in simply because I couldn't really get a great answer from the jQm team on whether or not we needed to support this. I know that the original iPhone is affected by this, but that's about it :-.

I say good riddance. Just let someone complain!


That's a relief...




@orkel, epic amounts of research there!


@mikesherov thanks, it did take a lot of patience, but, please, dont trust me, dont land this, until somebody else check this at least some of them browsers i listed above


@orkel did you collect devices or did you use emulators ? or both ?


From my research, all I could find was the original iPhone that this impacted. One other note, you should remove the object from the grunt JSHint expected globals array.


And by object, I mean WebkitPoint.


@jaubourg both, mostly emulators, except for android and old iphone, do you have a reason not to trust those emulators?
@mikesherov done, thanks!


@orkel I do trust emulators, I was just curious about the means ;)


Sizes - compared to master 252683 (-397) dist/jquery.js 92521 (-221) dist/jquery.min.js 33162 (-77) dist/jquery.min.js.gz

@dmethvin dmethvin closed this in d0763a3 May 27, 2012

Excellent detective work @orkel, thanks!


Looks like we have some test failures from this?

Related discussion on and cf672a2, I still think asking for the offset of a disconnected node is a bad idea. 💣


I think expecting anything about display/style from a detached node is a bad idea...


Webkit doesn't not return style information on disconnected node unless they are inline styles. Any test for style info on disconnected nodes is a bad test IMHO.


Oh, yeah, just saw the failures. We should still be normalizing to 0 for disconnected nodes. It's the only sane response besides an exception.

@markelog markelog added a commit to markelog/jquery that referenced this pull request Jun 29, 2012
@markelog @dmethvin markelog + dmethvin Followup gh-796. Eliminate try-catch in oldIE, closes gh-799. 8261662
Yaffle commented May 17, 2013

webkitConvertPointFromNodeToPage works even if css transformation was applied unlike getBoundingClientRect

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment