Created attachment 461760 [details] screenshot of codepen with video element that has disablePictureInPicture attribute I created a simple HTML with a video https://codepen.io/anything/pen/Barvozw <video id='video' disablePictureInPicture controls="controls" preload='none' width="600" poster="https://assets.codepen.io/32795/poster.png"> <source id='mp4' src="http://media.w3.org/2010/05/sintel/trailer.mp4" type='video/mp4' /> </video> I want to disable PictureInPicture and used the disablePictureInPicture attribute on the video element but that is ignored in iOS 15.6 Safari.
<rdar://problem/98952438>
WebKit has no plans to implement disablePictureInPicture. Allowing websites to disable user’s control over video playback is an anti-feature and user hostile.
Hi Devin, Do you think I've added this bug to make you or WebKit build an anti-feature and user-hostile feature? Check out two popular websites used by millions of users with a poor experience due to your ambition not to implement an HTML spec. 1: twitch - you start fullscreen, set pip, and navigate to another twitch page (it stops the pip playback with a back image) 2: youtube - start fullscreen, click pip, and returns you to the page as it was before fullscreen (basically reverts your pip action) This is a feature mentioned in a spec, not invented by me: https://www.w3.org/TR/picture-in-picture/#disable-pip If you genuinely cared about users (and their control over the video playback) you should start with your developer users that usually what their website/web app to retain customers and users instead of adding anti-features or at least don't tell me that you care about the users and you're just too lazy. This is already implemented in the most popular browsers, I guess that Safari is just the new IE.
(In reply to Adrian Florescu from comment #3) > you're just too lazy. I think you'll find that calling the developers of WebKit and Safari "lazy" will not convince any of them to take you seriously.
Sure, that is on me. I shouldn't add that word, but there was no way for me to edit after having second thoughts, but you have the power to allow this bug to be fixed. I'm truly hurt by your answers. Hope you understand that even if my words were not properly picked I am trying to file a bug in your system so that developers using your system have a better DX instead.
(In reply to Adrian Florescu from comment #5) > allow this bug to be fixed. From our point-of-view, this is not a bug. This is a policy decision. That websites go out of their way to break picture-in-picture mode is not a good reason to make breaking picture-in-picture mode _easier_. And that's what the `disablePictureInPicture` argument does: it breaks user's use of picture-in-picture mode. > developers using your system have a better DX instead. Please take a look at the W3C's "priority of constituencies", and note when they say "authors", they're speaking of "page authors"/"developers": <https://www.w3.org/TR/html-design-principles/#priority-of-constituencies> > In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors; This is a conflict between users and developers, and we will give the users' experience more weight than developers' experience.
Hi Jef, I still think that is better to ship a video element without a PIP option instead of a half-baked solution as Twitch and Youtube did. Users would still have a better experience not having a button instead of that button being there and not working properly -- or browsers (including Safari) allowing developers to break that experience. As Apple did with the Calculator app on iOS -- better not ship half-baked products -- this is what I wanted to do with my video player until I had a proper PIP solution that worked properly on all browsers. Also, how come this is marked as supported here: https://developer.mozilla.org/en-US/docs/Web/API/HTMLVideoElement/disablePictureInPicture and and here: https://caniuse.com/?search=disablePictureInPicture It's not my job to tell you what is a bug or not therefore I will not comment further unless you need my help in any way to test this or other details. Thank you for all your time and sorry for being unpolite, it was a major mistake on my part and I am sure you and your colleagues are top engineers!
(In reply to Adrian Florescu from comment #7) > Also, how come this is marked as supported here: > https://developer.mozilla.org/en-US/docs/Web/API/HTMLVideoElement/ > disablePictureInPicture and > > and here: > https://caniuse.com/?search=disablePictureInPicture The Picture-in-Picture specification says that User Agents "MUST reflect the content attribute of [disablePictureInPicture]", and WebKit does. It then says, when the disablePictureInPicture attribute is present, User Agents "SHOULD NOT play the video element in Picture-in-Picture". "MUST" and "SHOULD" are defined in terms of RFC 2119 <https://www.ietf.org/rfc/rfc2119.txt>. WebKit supports setting the disablePictureInPicture attribute, and it reflects that attribute to a DOM property of the same name. Therefore we meet the first requirement of the specification. That's why you see that property listed as "supported" in caniuse.com and MDN. Actually disabling picture-in-picture is not mandatory; the use of the word "SHOULD" rather than "MUST" is intentional. A User Agent does not actually need to block picture-in-picture to be compatible with the specification.