Bug 197613 – Clicks inside iframe doesn't work after it being scrolled

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: Frames

[Victor N]

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.

[Victor N]

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]

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]

<rdar://problem/50558703>

[Simon Fraser (smfr)]

Are you saying that with "Async frame scroll" turned off, you can still reproduce the bug with clicking buttons inside the iframe?

[Victor N]

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)]

Got it, thanks.

[Antti Koivisto]

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 ***