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 –
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.
@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.
Remove WebkitPoint from jshint and grunt
@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
Fix #11823. Remove webkitConvertPointFromNodeToPage. Closes gh-796.
Excellent detective work @orkel, thanks!
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. 💣
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.
Followup gh-796. Eliminate try-catch in oldIE, closes gh-799.
webkitConvertPointFromNodeToPage works even if css transformation was applied unlike getBoundingClientRect