Bug 197613

Summary: Clicks inside iframe doesn't work after it being scrolled
Product: WebKit Reporter: Victor N <victorsignup>
Component: FramesAssignee: Nobody <webkit-unassigned>
Status: RESOLVED DUPLICATE    
Severity: Normal CC: koivisto, simon.fraser, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: Safari 12   
Hardware: iPhone / iPad   
OS: iOS 12   
Attachments:
Description Flags
Screen capture of the reproduction case
none
Experimental feature none

Victor N
Reported 2019-05-06 08:28:13 PDT
Created attachment 369123 [details] Screen capture of the reproduction case Elements inside an iframe are unable to be taped after the iframe is scrolled using window.scrollTo() or window.scrollBy(). Reproduction steps: 1. Visit https://victornpb.github.io/ios-scrollable-iframe-issue/ 2. Click the buttons on the left, it changes color to show that it is working. 3. Click the "Scroll down" button and it scrolls the iframe down by 50 pixels. 4. After that the buttons doesn't work at all. A screen capture is attached to this issue as MP4 video. It works fine on Desktop Safari, this issue only happens on Mobile Safari.
Attachments
Screen capture of the reproduction case (3.70 MB, video/mp4)
2019-05-06 08:28 PDT, Victor N 		no flags
Details
Experimental feature (169.31 KB, image/png)
2019-05-06 11:08 PDT, Victor N 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Victor N
Comment 1 2019-05-06 11:08:57 PDT
Created attachment 369143 [details] Experimental feature Testing on other iPhones I couldn't reproduce it, then I found my phone had a experimental feature turned on called "Async Frame Scrolling". And it seems that it was turned on by default on 12.1, and it is not present on 12.2. Reverting to the old behavior of expanding the iframe to its content.
Victor N
Comment 2 2019-05-06 12:34:11 PDT
After further investigation, when you don't set the iframe to `scrolling=no` and a numeric height, the viewport (of the iframe) becomes the document height, so you can't actually scroll anywhere. This means the issue still reproducible without the "Async frame scroll". This behavior doesn't match anything else out there, on desktop or mobile, chrome on android works just as expected.
Radar WebKit Bug Importer
Comment 3 2019-05-07 15:39:11 PDT
<rdar://problem/50558703>
Simon Fraser (smfr)
Comment 4 2019-05-07 15:41:21 PDT
Are you saying that with "Async frame scroll" turned off, you can still reproduce the bug with clicking buttons inside the iframe?
Victor N
Comment 5 2019-05-07 16:38:50 PDT
Correct! Yes I can reproduce the issue with "Async frame scroll" turned off. The issue happens when the internal scrollbar of the iframe is scrolled using javascript. But there is a catch here, iOS have a non standard behavior, it expands the iframe height to the height of its content, eliminating the internal scrolling, hiding this bug (because you can't scroll). But if you force the iframe to NOT expand to its content so theres more content than the height (which is the way other browsers render it) and you scroll it down using JS, the "tap areas" becomes misaligned from the elements, making then inaccessible to taps. I found two ways of making the iframe not expand to its content: 1. Enabling "Async frame scroll" feature 2. Without Async frame scroll, set height of the iframe to a non percent value, and set scrolling=no e.g.: <iframe height="500" scrolling="no"></iframe> My guess is this is an optimization by the engine, it assumes that when scrolling=no, it doesn't need to recalculate the "tap areas", even though they can be changed from Javascript land not only from the user input.
Simon Fraser (smfr)
Comment 6 2019-05-07 16:44:06 PDT
Got it, thanks.
Antti Koivisto
Comment 7 2019-05-09 07:54:29 PDT
Async frame scrolling is now enabled by default and this bug should be resolved too. I think it works right even with async scrolling disabled in trunk but I haven't verified. *** This bug has been marked as a duplicate of bug 192303 ***
Note You need to log in before you can comment on or make changes to this bug.