Bug 204382 – REGRESSION (iOS 13): Removing an element inside of an iframe breaks the click area

• Status: NEW
• Component: UI Events

[Avram Eisner]

StackOverflow post here: https://stackoverflow.com/questions/58434598/ios-13-iframe-click-area-broken-after-dom-manipulation
A live demo can be seen here: https://codepen.io/labepiniimailwebtop/full/mddEpjP

As you can see, removing the image causes the click area of the button to move up above the rendering of the button so touching it does nothing. You can see the position of the button's click area in the web inspector.

[Radar WebKit Bug Importer]

<rdar://problem/57341213>

[Simon Fraser (smfr)]

Removal triggers scrolling; this must be about not communicating that new scroll position back to the web process.

[Avram Eisner]

(In reply to Simon Fraser (smfr) from comment #2)
> Removal triggers scrolling; this must be about not communicating that new
> scroll position back to the web process.

Ok, thanks for the comment Simon. In another example I came up with, attempting to scroll in this broken state makes the content jump up to align where the click areas are, but you are not able to scroll up to see what becomes cut off at the top. I should be able to link to a codepen that demonstrates that tomorrow.

[Avram Eisner]

OK, I can't create a codepen for that example because codepen applies 'overflow: hidden' to the outer html tag. If that property is removed, scrolling vertically after deleting the element makes the content visually jump up to match where the click area is, cutting off much of the content.

[Avram Eisner]

Simon, inspired by your comment, I discovered a JavaScript hack that fixes the issue. Adding

window.scrollTo({top: document.body.scrollTop});

after the element is removed repositions the click areas correctly. Just thought I'd let you know in case it helps fixing the bug in WebKit.