Bug 197613 - Clicks inside iframe doesn't work after it being scrolled
Summary: Clicks inside iframe doesn't work after it being scrolled
Status: RESOLVED DUPLICATE of bug 192303
Alias: None
Product: WebKit
Classification: Unclassified
Component: Frames (show other bugs)
Version: Safari 12
Hardware: iPhone / iPad iOS 12
: P2 Normal
Assignee: Nobody
Keywords: InRadar
Depends on:
Reported: 2019-05-06 08:28 PDT by Victor N
Modified: 2019-05-09 07:54 PDT (History)
3 users (show)

See Also:

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

Note You need to log in before you can comment on or make changes to this bug.
Description Victor N 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.
Comment 1 Victor N 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.
Comment 2 Victor N 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.
Comment 3 Radar WebKit Bug Importer 2019-05-07 15:39:11 PDT
Comment 4 Simon Fraser (smfr) 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?
Comment 5 Victor N 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.
Comment 6 Simon Fraser (smfr) 2019-05-07 16:44:06 PDT
Got it, thanks.
Comment 7 Antti Koivisto 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 ***