Created attachment 462575 [details] Sample html demonstrating the bug This bug occurs in Safari on iOS/iPadOS 16 and 15. Steps to reproduce: 1) Open the attachment index.html in Mobile Safari 2) Press the YouTube play button to start the video 3) Press the native pause button to pause the video 4) Press the native play button to play the video again Expected results: The native video controls remain on the screen for a few seconds, and after they disappear, you can bring them back by touching the video. Actual results: The native video controls disappear immediately after pressing play, and when you touch the video, the native controls appear momentarily and disappear immediately. It's extremely difficult to get the native controls to stay on the screen. If you open the Safari web inspector, disable Site-specific Hacks, and reload the page, then everything works as expected again. I'm still trying to determine exactly which quirk is causing this, but there are a couple that look relevant: https://github.com/WebKit/WebKit/blob/main/Source/WebCore/page/Quirks.cpp This bug is relevant to me because I have an iOS Safari extension that shows the native video controls on sites, and the Safari quirk breaks the feature for YouTube embeds. If you know of a workaround I could use that doesn't involve disabling Site-specific Hacks, I would appreciate it. Related: For some reason, another Safari quirk is to make YouTube videos show iOS 15 style video controls on iOS 16 unless the URL has the search parameter showinfo=0. This seems strange.
<rdar://problem/100367762>
Likely caused by https://commits.webkit.org/213411@main, a quirk/workaround for behavior introduced in https://trac.webkit.org/changeset/242798/webkit.
On further testing, I don't think the issue is restricted to iframes. That's just a coincidence, because the iframe has a src with the www.youtube.com domain, which is the same as in the site-specific hack. I can also reproduce the issue with the main frame of a page if I use Request Desktop Website in Mobile Safari (which is the default on iPad). Whereas if I use Request Mobile Website, the issue tends not to occur with the main frame, because the domain will be m.youtube.com, which isn't covered by the site-specific hack.
> I can also reproduce the issue with the main frame of a page if I use Request Desktop Website in Mobile Safari (which is the default on iPad). Default on iPads which are sending the desktop User agent (such as the iPad Pro). iPad mini is sending a different UA (iPadOS) and receives a mobile layout.