Bug 245612 – [Quirks] Site-specific hacks break native video controls on YouTube

• Component: Media
• Status: NEW

[Jeff Johnson]

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.

[Radar WebKit Bug Importer]

<rdar://problem/100367762>

[Jer Noble]

Likely caused by https://commits.webkit.org/213411@main, a quirk/workaround for behavior introduced in https://trac.webkit.org/changeset/242798/webkit.

[Jeff Johnson]

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.

[Karl Dubost]

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