Remove webkitConvertPointFromNodeToPage #796

Closed
wants to merge 2 commits into
from

Projects

None yet

6 participants

@markelog
Member

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

Member
Member

@rwldrn, hey, I already did that :)

Member

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

Member

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!

Member

That's a relief...

Member

\o/

Member

@orkel, epic amounts of research there!

Member

@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

Member

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

Member

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.

Member

And by object, I mean WebkitPoint.

Member

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

Member

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

Owner

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
Owner

Excellent detective work @orkel, thanks!

Owner

Looks like we have some test failures from this? http://swarm.jquery.org/job/163

Related discussion on http://bugs.jquery.com/ticket/4996 and cf672a2, I still think asking for the offset of a disconnected node is a bad idea. 💣

Member

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

Member

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.

Member

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