Created attachment 234347 [details] xCode Project to reproduce the issue Reproduced on iOS8 Beta 2. Version: 538.39 (Your form needs updating. :D ) navigator.userAgent: "Mozilla/5.0 (iPhone; CPU iPhone OS 8_0 like Mac OS X) AppleWebKit/538.39 (KHTML, like Gecko) Mobile/12A4297e" Salesforce embeds all its customer VisualForce pages in Salesforce1 this way, so not having selecting working for all of them would be a very big deal. I've embedded an xCode Project that you can run to reproduce, I'll explain below the best I can as well. (Excuse my sloppiness, I don't actually do any xCode programming, I simply learned this much as to get the issue isolated and make a bug report) To Reproduce. Start with this DOM Structure (already setup in the included xCode project) Position a DIV absolutely with these styles { position: absolute; top: 0; bottom: 0; left: 0; right: 0 } Inside that, include a div with these styles { height: 100%; overflow: auto; -webkit-overflow-scrolling: touch; } Inside that include an iframe with these styles { height: 100% } The iframe should link to a long page with input elements up and down the page. You could just link to the page I created for this http://www.justise.com/prototype/scrolltotop2.html To reproduce the actual issue now Without Scrolling you should be able to click any of the radio buttons Now scroll down the page Trying to click any of the radio buttons on the left results in an offset click. One of the radio buttons below your click will receive the event. Expected: The radio button I clicked on gets focus Actual: The click event is offset the amount the iframe was scrolled. Notes: The first div that is positioned absolutely is a major culprit here. I could not reproduce it till I added that code in. I'm simply reproducing the structure of the Salesforce1 application in this example. While it makes sense not to wrap it all in the absolutely positioned div, it's just the way our app is structured currently and we would prefer not to have to re-architect it to work around issues such as this.
I can reproduce with WebKit ToT. It seems to be only with the old UIWebView, I cannot reproduce with WKWebView. Simon, any idea what is going on? My first suspect was the iframe but the wrong hit testing only happens when you scroll. Kris, if you get a chance, can you try the same use case with WKWebView in iOS 8? WKWebView is a new API using WebKit2, everything is brand new. It is a lot more powerful than the old UIWebView.
Will try thx.
Doesn't appear to reproduce on the new WKWebView. It'll take us a while to get the Salesforce app onto iOS8 though since we'll still have quite a few customers on iOS7, so this will still be an issue. So far, the WKWebView is functioning wonderfully though. Kudos.
(In reply to comment #3) > Doesn't appear to reproduce on the new WKWebView. > > It'll take us a while to get the Salesforce app onto iOS8 though since we'll still have quite a few customers on iOS7, so this will still be an issue. > > So far, the WKWebView is functioning wonderfully though. Kudos. Even if someone finds the issue, that's not gonna go back to iOS 7. I suspect it is related to the WAKView hierarchy which is specific to UIWebView. I don't think fixing this for UIWebView should be high priority, our time would be better spent fixing more WKWebView issues.
A few other notes that hopefully make it easier to identity and more likely to be fixed: This not only affects native and hybrid downloadable apps using UIWebview, but even oneapp home screen launchers created from within Safari. Is this the same renderer or do they share come library code? This is still evident in iOS 8.0.2 It can be reproduce in XCode 6.0.1 emulators for iOS 8. Although the clicked target element is offset by the scroll amount, the event screenX and screenY attributes seem to be correct, returning the position of the actual element, not the reacting element from lower in the page. This also affects touch and hold to select text or paste from the clipboard. If I wrap the iframe with a div styled like this, it always shows the problem: height:100%; overflow:auto; -webkit-overflow-scrolling: touch; position:relative; But if I remove one line, overflow:auto, the issues goes away. height:100%; -webkit-overflow-scrolling: touch; position:relative;
Also, an earlier post mentioned that any fix wouldn't likely be backported to 7.x. At least in our testing, we have not seen the issue in anything prior to iOS 8.0.
Created attachment 239082 [details] Patch
Comment on attachment 239082 [details] Patch Clearing flags on attachment: 239082 Committed r174199: <http://trac.webkit.org/changeset/174199>
All reviewed patches have been landed. Closing bug.
This is great news, thanks. Is there a way to identify which iOS version will contain this fix?
(In reply to comment #10) > This is great news, thanks. > > Is there a way to identify which iOS version will contain this fix? Not here, we do not discuss release plans publicly. You should contact your Apple evangelist directly to get more information.