Enable media.videocontrols.picture-in-picture.respect-disablePictureInPicture
Categories
(Toolkit :: Picture-in-Picture, task, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox116 | --- | fixed |
People
(Reporter: niklas, Assigned: niklas)
References
Details
Attachments
(1 file)
Currently (when bug 1811321 lands) media.videocontrols.picture-in-picture.respect-disablePictureInPicture
is enabled for Nightly only. We will want to enable for all
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 1•1 years ago
|
||
Updated•1 years ago
|
Comment 3•1 years ago
|
||
bugherder |
Comment 4•1 year ago
|
||
Hi, The property HTMLVideoElement.disablePictureInPicture
is not showing up/passing the WPT live tests or the bcd collector test: https://mdn-bcd-collector.gooborg.com/tests/api/HTMLVideoElement/disablePictureInPicture
There is a comment here "While the flag mentioned in that PR is indeed enabled by default, the property is not defined in the WebIDL.". I can see in https://searchfox.org/mozilla-central/source/dom/webidl/HTMLVideoElement.webidl it appears as an "InstrumentedProps".
[Exposed=Window,
InstrumentedProps=(cancelVideoFrameCallback,
>>>>>>>>>> disablePictureInPicture,
onenterpictureinpicture,
onleavepictureinpicture,
playsInline,
requestPictureInPicture,
requestVideoFrameCallback)]
interface HTMLVideoElement : HTMLMediaElement {
[HTMLConstructor] constructor();
...
So the question is "should this work" and if so, what do we need to get our tests to show that it works?
Discussion follows from https://github.com/mdn/browser-compat-data/pull/21029
Comment 5•1 year ago
|
||
Ping! Can we please have a response to this ^^^. As far as we can tell disablePictureInPicture
is NOT supported - according to WPT and bcd collector tests. If you can't confirm, the intent is to mark this as not supported.
Comment 6•1 year ago
|
||
OK. We have undone the indication that this feature is supported in compatibility data.
Comment 7•1 year ago
|
||
Hi, sorry about the delay, I was out for a couple days. As far as I can tell, we do intend to be passing this test. We'll file a separate bug to update the appropriate WebIDL, and I think that should take care of this.
Note though that we provide an implementation of the attribute behavior that is deliberately not spec-compliant, and we have no plans to change that. I would assume that the compatibility data needs to reflect this fact.
Comment 8•1 year ago
|
||
Note though that we provide an implementation of the attribute behavior that is deliberately not spec-compliant, and we have no plans to change that. I would assume that the compatibility data needs to reflect this fact.
Hi Molly,
The compatibility data was reverted to mention the version this was provided in. However it doesn't capture that the behaviour is non-spec-compliant. We could add this as a note if you can provide information about what it actually does that differs?
Comment 9•1 year ago
|
||
So, there's two things:
- We implement the
disablePictureInPicture
attribute, but none of the rest of the PIP spec. - Our implementation of
disablePictureInPicture
does not fully disable picture-in-picture; we'll hide our usual button that overlays the video, but still allow the user to override.
Thanks!
Comment 10•1 year ago
•
|
||
Thanks @molly. The BCD team are asking the hard questions in https://github.com/mdn/browser-compat-data/pull/21263 about how this can work if it is undefined:
"HTMLVideoElement.prototype.disablePictureInPicture is undefined, so how is it supported? Is it simply that setting the property to true has an effect?"
Is that the case? i.e. setting the property, even though it is undefined initially, hides the overlay button?
That is what I assumed, but would be good to have it "said".
Comment 11•1 year ago
|
||
(In reply to Hamish Willee from comment #10)
Is that the case? i.e. setting the property, even though it is undefined initially, hides the overlay button?
That is exactly correct, yes.
Description
•