Closed Bug 1611831 Opened 4 years ago Closed 4 years ago

disablePictureInPicture attribute does not work

Categories

(Toolkit :: Video/Audio Controls, defect)

Product:
Toolkit
Component:
Video/Audio Controls
Version:
72 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1811321

People

(Reporter: bjetsch, Unassigned, NeedInfo)

References

Details

+++ This bug was initially created as a clone of Bug #1607720 +++

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:72.0) Gecko/20100101 Firefox/72.0

Steps to reproduce:

Create a video element with a "disablePictureInPicture" attribute (as per spec https://w3c.github.io/picture-in-picture/#disable-pip).

Actual results:

The blue hovering PiP button appeared anyway, and the PiP option was present in the context menu.

Expected results:

According to the spec:
"If the disablePictureInPicture attribute is present on the video element, the user agent SHOULD NOT play the video element in Picture-in-Picture or present any UI to do so."

Works correctly on Chrome (the context menu option gets disabled).

If someone can provide hints about the relevant source files, I might be able to contribute a patch.

Since the Bug ticket was closed without much discussion, I felt forced to create this clone. The problem was not resolved and the statement, that the intentional ignoring of the disablePictureInPicture attribute is not a solution for cases, when a page provider don't want his content grabbed without permission.

In the picture in picture window, you can't display your ads, overlays or anything else and thus it breaks player implementations of content providers. Is there any reason, why a feature should be allowed to ignore the clear request to disable it? I can't believe this is desired behavior overall and should be controllable in some way, even if it's a non standardized solution.

Component: Audio/Video: Playback → Video/Audio Controls
Product: Core → Toolkit

I'd also like to ask that support for disablePictureInPicture (or your own non-standard Firefox specific way to display picture in picture) be added soon, please. I work for a video content company targeted at enterprise users, not consumers. We have our own custom video player that overplays powerpoint presentations, chapter markers, interactive prompts, etc, into the video playback experience. To our users playing a video in our system is so much more than just letting a mp4 file play. This new picture in picture feature, while great for consumers and for "normal" videos, leads to an undesirable user experience for our enterprise customers. Rather than instructing our entire customer base on how to globally disable picture in picture in Firefox and thus deprive them of this great feature on sites where it makes sense, I would much rather add some kind of attribute on our own video tags to just disable it in our application.

Thank you so much for your consideration.

The decision to not follow the disablePictureInPicture attribute was chosen to act in the users best interests.

I think we could consider adding a policy that disables the picture-in-picture feature for enterprise systems. Mike, has this been considered?

Flags: needinfo?(mozilla)

I think we could consider adding a policy that disables the picture-in-picture feature for enterprise systems. Mike, has this been considered?

That wouldn't really help this scenario unless we could do it on a per site basis (which would require changes to pip)

The decision to not follow the disablePictureInPicture attribute was chosen to act in the users best interests.

We could do this better and still act in the users best interests. We could honor the attribute and provide a way for the user to override it for a site.

It seems odd that we're disregarding the spec with regards to this.

Flags: needinfo?(mozilla)

(In reply to Mike Kaply [:mkaply] from comment #3)

We could do this better and still act in the users best interests. We could honor the attribute and provide a way for the user to override it for a site.

I'll defer to mconley for this since he's more in the loop with what decisions we've made.

It seems odd that we're disregarding the spec with regards to this.

To be fair, I don't think we're following this spec on our implementation anyways. See https://github.com/mozilla/standards-positions/issues/72

(In reply to Mike Kaply [:mkaply] from comment #3)

We could do this better and still act in the users best interests. We could honor the attribute and provide a way for the user to override it for a site.

See https://hacks.mozilla.org/2020/01/how-we-built-picture-in-picture-in-firefox-desktop/ - in particular, the comparison with Chrome's implementation - for our rationale here.

We explicitly don't want to restrict the user in what videos they can open in Picture-in-Picture, and we have intentionally deferred implementing any part of the Web API spec, including the disablePictureInPicture attribute.

It seems odd that we're disregarding the spec with regards to this.

At this time, we're not implementing any part of the spec. Picture-in-Picture in Firefox is a browser feature, and is not exposed in any way to the web at large.

I'm closing this bug as WONTFIX, since (at this time) we're not planning on implementing or shipping any part of the Picture-in-Picture Web API. We can re-open this bug if we decide down the line to ship some or all of the Web API.

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX

I would ask you to please reconsider this decision. It does not matter to me whether or not Firefox supports the disablePictureInPicture attribute specifically. What I am asking you for is some way that this feature can be disabled on sites where it causes a very bad user experience.

I completely understand and agree with your logic on why things have been implemented the way they have been to give more control back to the end user and provide them with a better user experience. However, in my particular enterprise use case this freedom given to the end user causes them to have a worse user experience. If they go into PIP mode then we lose the ability to show our slide overlays, our interactive prompts, etc. Worse yet is if the user clicks this button during a course or certification that they are required to complete in order to remain employed at their company (this is a real use case!) they may never see the button. For our application the MP4 file is just one component of the "content" that our enterprise users are expected, and in some cases mandated, to consume.

I understand that this is a slippery slope and having any kind of way to disable this freedom from a user would be jumped upon by bad actors. But please think about the damage that could be caused to an end user in a use case like ours. Perhaps the way to go here is a simple whitelist of sites where the PNP code should be disabled? We'd be very happy to talk you through our product, our use cases, to help you better understand that this feature is not a good user experience for our users. And at the end of the day we all have the same goal -- to deliver the best possible user experience to our respective users.

Flags: needinfo?(astevenson)

ni'ing astevenson to put his feelers out on this once he's back from PTO.

I am glad to see some conversation on this topic and I am appreciate your time for looking into it. Sadly this ticket was also resolved as won't fix and I totally get the point of it, if there are no plans currently to address this. Non the less I wanted to leave another comment, because I don't believe this issue is something only 2 companies on this planet have to face. Maybe they just didn't noticed it yet or didn't find the time to spend effort on it. Maybe they also found this ticket and just waited until something happend - I don't know. It doesn't matter so much. The really important thing is, that the current chosen approach can cause trouble, if the user experience is not only watching a video. There are implementations out there, where overlays, additional information and other video API features contribute to the product itself and those are likely to break if the video is taken out of context.

I really like the picture in picture feature in general and it's a great addition to the browser features for sure, but there are scenarios when this harms the overall UX of a product or even breaks it completely. Therefore, even if it's breaking the idea of giving always the same user experience, giving content providers a chance to choose is always a good thing. In general I am a big fan of opt-in, so whoever wants to allow a feature, he should be able to activate it, if it makes sense. But I totally get, that the idea was to allow this new feature to work even on older pages with video content, so I am fine with the automatic opt-in as long as there is some kind of opt-out, if it is necessary. In an enterprise field you can brief the users to deactivate the feature in the browser settings of course, but this kills the idea of this feature. As a content provider, you just can't tell all your users: "Hey please kill that feature for our page and break it on every other page aswell, please" This is even worse, than having not the same UX for pip on every page in my opinion.

Long story short: The idea behind the pip feature is great and it's a great addition for the users. Non the less it feels a little wrong, to not have any choice and don't have any control to maintain the UX you want to provide as a company, especially if the video alone is not everything the video player provides. I would appreciate it very much, if you could reconsider the decision to not allow any way to chose or control this feature.

Thank you very much and have a nice day

We are one of those enterprise customers who are really sad this isn't an opt-out feature. We have a custom video player that incorporates much richer interactions, quizzing, clickable video locations, etc. PIP basically breaks all those features and this response forces us to tell our end users to disable pip themselves, ignore the bright blue button, or switch to another browser.

PIP is great and we offer it to our users whenever possible, however not being able to opt out programmatically degrades our user's experience.

In addition to the arguments above, here are a couple more situations where having PiP wouldn't make sense:

  1. Landing page videos. Some websites use a large video as a background (instead of the so-called hero image). This content is not made to be consumed as stand-alone content.

  2. Using video element as part of an advanced web application (think video editing software online) that may want to utilize the video element for purposes other than end-user content consumption. For example, use multiple video elements to display video clips (parts of the full source video), frames etc. Using PiP functionality in these cases would just not make sense.

In addition to general reasons why PiP in some cases wouldn't be desirable or sensible, I think this blue PiP overlay (as opposed to just being a context menu option) is also visually invasive. It is a rare case where the browser imposes its own style on the rendered content (viewport) with no ability for the developers to style it or hide it.

Is Firefox adding a play button overlay over <video> elements similar to the PiP slide-out on the right border? I would like to be able to opt-out of both of these.

(In reply to james from comment #12)

Is Firefox adding a play button overlay over <video> elements similar to the PiP slide-out on the right border? I would like to be able to opt-out of both of these.

Nevermind, I see Firefox is adding this in response to the controls attribute of the <video> element.

Hello all,

Although I've seen that the bug has been closed as "wontfix" I wanted to add my input here as I'm coming from a different field that hasn't been represented yet. Besides enterprise costumers, the scientific community is highly affected by this issue too. I'm a neuroscientist currently working on implementing some online testing that requires a lot of video customization and specific user interactions. These implementations, though, are broken by PIP. Besides the problem of worsened user experience enterprise costumers have voiced here, we also run into the problem that any data from individuals that use PIP would be corrupted and unusable. This wastes the scientist's time, the participant's time, and grant funding money. In the past, what others in the scientific community have done about this is to simply not allow any participant to use Firefox. This, though, makes the experiment less accessible, creates a sampling bias, and decreases sample size.

I understand the reasons given here as to the decision to not implement the feature, but for the benefit of giving individual users control, there is a detriment to organization users. If at all possible, I would ask for the decision to be reconsidered and to allow someway for developers to control the PIP features on Mozilla.

Thank you.

Use case where this is needed: Online video course where users must not lose focus of the active window while the video course is playing. Chrome respects this attribute—why no FF?

We're developing an online platform where pip makes absolutely no sense. It is quite annoying to have this big blue bar across all our videos. It would be great to have some kind of opt-out method.

When showing controls on the video the bar transforms in some kind of round button. Why not add it to the controls bar?

As a user, I don't see any use for pip anyway, and the blue bar is quite intrusive. Why not remove the bar completely and have this only in the context menu?

My company also works in the enterprise space, in healthcare, on our telehealth application. We are super sad to see here that you won't be honoring the standard. Could you PLEASE reconsider? This is supremely annoying to our clients, and being enterprise, it is very difficult for them to update the FF settings of thousands of browsers in their organization. I believe a few other folks have also listed some very good reasons why you should honor the standard.

I like the idea of honoring the standard by default, buy allowing users to override/force this setting. Can we please go that route?

Hello th317erd.

You're welcome to disable the feature on the machines you manage using the enterprise policy added in bug 1619658 (see https://github.com/mozilla/policy-templates for policy templates).

My understanding is that Mozilla is choosing to ignore the W3C spec and give the bird to the entire web dev community.

There seems to many reasons already outlined above that proves why people would not want this behavior. Here is another...

I am 3D transforming a local video element to flip the render horizontally in order to mirror the user's camera preview. In doing so, your fancy tooltips display backwards and are no longer readable or useful to the user. It would be better if you allowed developers to enable the feature when and where it makes sense to do so instead of forcing it upon our products and applications.

There appears to be confusion here - some commenters in this bug seem to think we have implemented part of the proposed Picture-in-Picture Web API spec, and have failed to include support for the disablePictureInPicture attribute.

To be absolutely clear to readers of this bug, no part of the proposed Picture-in-Picture WebAPI spec has been implemented. The Picture-in-Picture feature in Firefox is a browser feature that is not in any way exposed to web properties. The feature as implemented does not expose any API surface for web pages whatsoever.

I don't think it matters if you implemented a feature to the W3C specifications or not. The point (and problem) still remain: FireFox is adding custom visual UI to pages that isn't controllable by site authors. There have already been numerous really good reasons why this is a problem. These are some of the already good points made as to why this is a problem, but I am sure more brain-storming or feedback from the community could provide some more:

  1. Mirroring the video mirrors the PIP controls FF imposes (we are running into this issue in our organization)
  2. Custom captions/controls that an author might want to put "over" the video"
  3. Educational/Healthcare/Proprietary apps that need to remove the PIP controls (for any number of good reasons)
  4. Videos as the background of the site

The argument here as I understand it is that we want to "give users control"... really? Why not just let them control all the CSS of the site? Or the javascript resources? Or the images that are loaded? Why not let them disable/"control" DRM (this would be a feature a lot of users would love to "control")? Or, while we are at it, everything else? This argument seems devoid of reason to me.

A browser is (and always has been) essentially a canvas for the artists that work on it. It should render exactly what the authors ask it to render, and nothing more or less. This funky shift in "let the user decide" not only deviates from decades of a "clean canvas" for authors, but also is a complete deviation from how the web has always worked.

By FireFox imposing this "standard" on authors you are essentially removing the ability to author things as desired/needed, meaning you are making FF less desirable to authors (and ultimately less desirable to users when site authors start adding browser blocking). FYI: As an organization we are about to block Firefox as a supported browser ourselves simply because of this.

Bottom-line: Your community is telling you this "feature" is broken and undesirable, and that we have now been forced (by your own hand) to stop using your product... I think maybe you should listen?

  1. Mirroring the video mirrors the PIP controls FF imposes (we are running into this issue in our organization)

For videos that mirror by using transform: scaleX(-1);, this should be fixed by bug 1672401 in Firefox 84.

  1. Custom captions/controls that an author might want to put "over" the video"

Nothing about the Picture-in-Picture toggle prevents site authors from putting captions or controls over the video.

  1. Educational/Healthcare/Proprietary apps that need to remove the PIP controls (for any number of good reasons)

"good reasons" is doing a lot of work there, and I think where we're primarily in disagreement.

  1. Videos as the background of the site

Hopefully these videos are less than 45s long! If so, then the toggle shouldn't appear for them.

Why not just let them control all the CSS of the site?

Yes. These are called user style sheets.

Or the javascript resources?

Users can run their own script on pages using user scripts.

Or the images that are loaded?

The page info dialog allows users to analyze and download the images that are loaded. So do the built-in Dev Tools (though the page info dialog is probably more user friendly for that use case).

Why not let them disable/"control" DRM

Disabling DRM can be done in about:preferences by unchecking "Play DRM-controlled content". If you mean users should be allowed to have full control over DRM protected content, I am sympathetic. Mozilla lost this battle. Allowing users to break the DRM would mean we'd be violating the DCMA (in the US, at least), and probably violating our Widevine license while we're at it. No great options there, except to allow users to disable DRM entirely if they wish (as I described earlier).

The argument here as I understand it is that we want to "give users control"... really? ... Or, while we are at it, everything else?

Yes, ideally, we would do this. This philosophy is very in line with Mozilla's mission.

A browser is (and always has been) essentially a canvas for the artists that work on it. It should render exactly what the authors ask it to render, and nothing more or less.

We are in disagreement. The browser is a user agent.

By FireFox imposing this "standard"

There is no standard here being implemented or applied. It is a browser feature, like Tracking Protection.

Your community is telling you this "feature" is broken and undesirable, and that we have now been forced (by your own hand) to stop using your product... I think maybe you should listen?

I'm am listening to you. I am just not agreeing with you. So far I have heard no new information that would cause us to reconsider our position here.

My point to this is that the implementation of the "picture-in-picture" capability is more or less the same concept as to what is available within Chromium and Safari, and while obviously the underlying approach taken to achieve this is within the browser itself is different, it is still the exact same feature from the end user's perspective!

I see no reason why Firefox cannot support reading this disablePictureInPicture attribute when scanning <video> elements and using this to disable/hide the PIP overlay when it is set; It would give web developers the capability to specify when they would like to hide this feature/capability and enhance control over the user experience (since relying on a local security policy setting is not achievable in a public-access situation)

Maybe I'm oversimplifying it, but from what I've read, Firefox is scanning the DOM for the existence of <video> elements and uses a shadow DOM to display the PIP overlay on these elements when found (as well as the option added to the right-click context menu); Updating this approach to prevent doing this when the disablePictureInPicture attribute is defined on these <video> elements doesn't seem like a big ask or all that difficult to achieve from a programming perspective, and this apprehension to do so is beyond me.

Why you wouldn't want to provide the best experience to both end-users and web developers (while also adhering to the specifications for PIP by the W3C) by supporting this request is truly baffling...

I posted my thoughts on this feature almost a year ago now. I was contacted by a PM from Mozilla, provided more info, never heard back. This feature is really disruptive to my company's enterprise video application. I provided, via email to the Mozilla PM, what I thought was lots of good contextual information as to why this is problematic. The bottom like is that Mozilla should trust that corporations making Web based products know what is good for our own end users. I understand exactly why you are trying to prevent most sites from taking this "freedom" away from the end user - I get that, I really do. But there 100% are cases where this "freedom" results in really problematic behaviors for these end users that they are totally unaware of. If they click that PIP button they no longer get credit for viewing everything in the video, as our overlays and other rich content we superimpose over videos or sync with video playback stop working.

There is a middle ground here. You can preserve this freedom for end users on the average web site, while not harming other end users in enterprise web applications. You can develop a whitelist and make companies like ours actively demonstrate to Mozilla why we need to be on the whitelist, and how we are not doing this to step on the freedom of our users. It's more overhead on the part of Mozilla, but at the end of the day it delivers a better end user experience to ALL users, not just for users of the average web site where popping a random standlone video into PIP mode isn't going to mess anything else out.

I am very happy to discuss further via email / phone / zoom / whatever if need be. Please reconsider your position on this. It can be very harmful to end users of enterprise web applications.

Thanks for the consideration!

I wholly agree with everything @ouija has said. For what it’s worth we have stopped loading of our online course within FF and directed users to another browser and haven’t looked back. When this many people have voiced issues over a “feature” and project devs remain stubborn sometimes the only answer is to find another solution.

Firefox's decision to punt on disablePictureInPicture is unfortunate. Browser developers cannot anticipate every application of video in web applications, and, in fact, there are many applications where picture-in-picture is disruptive to the user experience.

In our application with live video, the picture-in-picture icon is a nuisance, so, like Art Geigel, we now direct users away from Firefox to Chromium-based browsers.

I urge Firefox developers to reconsider the decision not to provide a way to disable picture-in-picture.

I understand part of the reasons why you decided to close this. But let me explain why in our case not having disablePictureInPicture hurts our users and us.

Our company developed a web applications that helps Spanish teachers in their work by providing educational content for kids and a Learning Management System that let's them track their students progress. If students activate the picture in picture feature not only they are not paying all their attention to the video, which is bad enough, but also the javascript code that reports their progress to the backend via AJAX calls doesn't execute.

This creates really stressful situations for them, because they have done their homework but it's not registered. Our clients, the teachers, which in the current pandemic situation have already enough problems tracking the progress of their students, then receive a lot of angry parent calls and emails complaining about how their children did all the work and receive no feedback about it.

Respectfully, I do think you should reconsider this decision. I really love Firefox and it's painful for to have to say our users to not use it because of this problem-

I'd like to voice my support for allowing this to be disabled per the standard.

Understood in Mozilla this is a "browser feature" and not a standard, but that's a handwavy response at best. The "browser feature" clearly implements functionality that is included in the Picture-in-Picture Web API, so it is hardly unreasonable for Mozilla's "browser feature" to be in alignment with web standards that have similar functionality.

Heck, it doesn't even have to be disablePictureInPicture; just some way--any way--to achieve the same end goal is at least in alignment with the standard, which I would hope Mozilla someday aspires to implement.

Please, for the love of tech, implement disablePictureInPicture flag to turn off this feature on a per video basis, sign on as editors on the W3C PIP Spec and make it more to your liking or just implement the spec as-is.

I can't begin to imagine the stress you may be under to deliver unique features against Chrome, Safari and Edge, and I can only imagine that this feature was sold to the C-suite as a Hail Mary to save Firefox's future from the dustbin, but you are really upsetting developers who are saying they will block access to their products from visitors using your browser directing them to spec-compliant browsers like Chrome and Safari.

According to statscounter.com, Firefox's global market share in Jan 2021 was 3.65%. For context, Firefox had 4.7% in Jan 2020 (a difference of 1.05%). I can only imagine that figure shrinking by another 1% by the end of 2021 if issues like this continue to get marked as "Won't Do." Microsoft Edge is closing in on Firefox with 3.23% (Jan 2021).

I guess the question for developers is "should we even bother with Firefox if it's on a trajectory to obscurity?" I usually wait until 2% to drop support for a browser, but I might make an exception when FF hits 3%.

https://gs.statcounter.com/browser-market-share

The picture-in-picture button interferes with other controls that happen to be on the same position.

For example, I tried to close YouTube's "More videos" box that it shows when a video is paused. But pressing the cross on the corner of the box instead activated picture-in-picture even though the cross was more prominent that the picture-in-picture icon. See image for reference:
https://i.imgur.com/vJBJbWO.png

This was highly unexpected. Firefox essentially breaks the UI by making a control that looks one way (a cross in the corner of the "More videos" box) actually do something else (activate picture-in-picture). You can't seriously maintain that this is to create the best possible user experience.

Even if the issue above was tweaked by ensuring the picture-in-picture toggle is overlaid on top of other controls (since it takes precedence), in such a way that the toggle would be visible and the cross (or other control) hidden behind it, this would still render the other control unusable.

When Mike Conley (:mconley) says "Nothing about the Picture-in-Picture toggle prevents site authors from putting captions or controls over the video.", this is simply not true. Controls that happen to occupy the same space as the picture-in-picture toggle don't work and create misleading or unusable UI.

What exactly are page creators meant to handle this issue? Are they meant to be minutely aware of where in a video the browser will display the toggle and ensure nothing else is shown there? Or how can they ensure their own controls will not be rendered unusable due to the imposed browser toggle?

Flags: needinfo?(mconley)

(In reply to Rune Johansen from comment #34)

The picture-in-picture button interferes with other controls that happen to be on the same position.

For example, I tried to close YouTube's "More videos" box that it shows when a video is paused. But pressing the cross on the corner of the box instead activated picture-in-picture even though the cross was more prominent that the picture-in-picture icon. See image for reference:
https://i.imgur.com/vJBJbWO.png

This was highly unexpected. Firefox essentially breaks the UI by making a control that looks one way (a cross in the corner of the "More videos" box) actually do something else (activate picture-in-picture). You can't seriously maintain that this is to create the best possible user experience.

Thanks, Rune. That sounds like a separate bug. Firefox does make an effort to not trigger Picture-in-Picture when the user clicks on a surface that's overlaid on top of the toggle that is sufficiently opaque (see bug 1666739). Could you please file a new bug with your steps-to-reproduce (in particular, how to get into the state such that the "More videos" box appears for you) so that we can try tuning the threshold? Feel free to needinfo me on that bug, and I'll look into it.

Flags: needinfo?(mconley) → needinfo?(rune)

Hi,
this is my first reply. Hope my solution that works for me might help you too.
I use a transparent data:image filled iFrame over the <video>. Events delegated via iFrame communication message sys. in FiFo. to the script which controls the video.
Funfact: make the the video 2px each side smaller than the iFrame -

But still when you superdooper slowly hover over the edges. the PIP cta appears - but ! unclickable.
Note: your videos must be longer than 15sec.

@Mozilla => TOFIX
https://w3c.github.io/picture-in-picture/#disable-pip

Mike and Andreas - please try to explain me the benefit.. really.
https://hacks.mozilla.org/2020/01/how-we-built-picture-in-picture-in-firefox-desktop/

twitter @mooraker6 send me a pizza, coffee or a snack for my dog, if you like and it helped you :)

(In reply to Mike Conley from comment #24 at https://bugzilla.mozilla.org/show_bug.cgi?id=1611831#c24)

Hi Mike! Thank you for all your work at Mozilla.

Could you be overlooking the fact that giving the user a given option also brings with it natural expectations, which if unfulfillable by the application developer, leads to an experience that inevitably breaches those expectations, which constitutes broken functionality, also known as buggy behaviour, which is objectively a worse user experience? Isn't this enough for you to grant opt outs such as disablePictureInPicture?

I've also noted Mozilla Principle 8 at https://www.mozilla.org/en-CA/about/manifesto/:

"Transparent community-based processes promote participation, accountability and trust."

I'm wondering what community based process is involved in decisions such as these? Is there a vote among the community? If none, then surely this should take place according to your own organization's principles?

If this is still not enough and you've taken this decision on a top-down basis, would I be right in suggesting then that you believe you necessarily know better than all web content creators, the vast majority of whose primary motivation in content creation is delivering the best possible user experience for their application, in determining that the compulsory inclusion of the PIP option makes a preferable user experience in all cases?

If so, can you share on which stated part of Mozilla's mission is this view being held, and if not explicitly stated quite to the extent I've described (e.g. "Individuals must have the ability to shape the internet and their own experiences on it.", which is far from this), from which other stated conversations, meeting minutes etc. has this view been reached?

I'm presuming you are duty-bound to share the information requested above by Principle 8 in the Mozilla Manifesto, in particular relation to the term "Transparent". Is that correct?

Flags: needinfo?(mconley)

I would also like to request that you reconsider your decision to resolve the lack of support for disablepictureinpicture with WONTFIX. We have a special video player that places a translucent overlay on the video, and the overlay is critical for our customers. Our customers do not want their videos to play without the overlay. An alternate approach would be for us to be able to access the stylesheet of the PIP player so that we can place the overlay there, but we have not found a way to do that either.

As a result, we had to make the unfortunate decision to not support FireFox for our video playback feature, and so we instruct users to install and use another browser.

Thank you for reconsidering your decision to reject support of this standard.

We have a special video player that places a translucent overlay on the video, and the overlay is critical for our customers. Our customers do not want their videos to play without the overlay.

So the issue is that the overlay disappears if you go to PiP?

(In reply to Mike Kaply [:mkaply] from comment #39)

So the issue is that the overlay disappears if you go to PiP?

You are now dodging and acting purposefully obtuse about what the community is asking Mozilla to do here. We are asking Mozilla to implement PiP based on the W3C spec which includes disablePictureInPicture on a video element. We are losing all confidence in Mozilla's ability to deliver a standard-compliant experience here.

(In reply to kgbedell from comment #40)

You are now dodging and acting purposefully obtuse about what the community is asking Mozilla to do here. We are asking Mozilla to implement PiP based on the W3C spec which includes disablePictureInPicture on a video element. We are losing all confidence in Mozilla's ability to deliver a standard-compliant experience here.

Actually, no, I've been actively working on trying to solve this, as you know because I've sent emails to you (which weren't responded to).

I'm asking about this specific use case to make sure it's covered in the proposal I'm working on.

(In reply to Mike Kaply [:mkaply] from comment #39)

We have a special video player that places a translucent overlay on the video, and the overlay is critical for our customers. Our customers do not want their videos to play without the overlay.

So the issue is that the overlay disappears if you go to PiP?

Hi Mike - Great to hear that you're working on this, and thanks for taking the time to understand my use case.

We could indeed do a browser-specific hack to put the overlay on the PiP, if it's supported. I dislike browser-specific hacks, but if that's what's required, we could investigate this approach... Note that I'm a product guy, not a developer: Would the overlay CSS apply to Firefox's PiP? It does not in other browsers... If it does I can ask my team to investigate this approach.

(In reply to Mike Kaply [:mkaply] from comment #41)

(In reply to kgbedell from comment #40)

You are now dodging and acting purposefully obtuse about what the community is asking Mozilla to do here. We are asking Mozilla to implement PiP based on the W3C spec which includes disablePictureInPicture on a video element. We are losing all confidence in Mozilla's ability to deliver a standard-compliant experience here.

Actually, no, I've been actively working on trying to solve this, as you know because I've sent emails to you (which weren't responded to).

I'm asking about this specific use case to make sure it's covered in the proposal I'm working on.

Hi Mike, I receive a lot of emails. I suppose I owe you an apology. I'm glad to hear it's being taken seriously. I'll look for your emails. Thanks.

Hi Mike,

I do not want to argue about specs but since its one of the arguments, I read this:

'Even when the attribute is absent, however, user agents may provide controls to affect playback of the media resource (e.g. play, pause, seeking, and volume controls), but such features should not interfere with the page's normal rendering. For example, such features could be exposed in the media element's context menu.'
source: https://www.w3.org/TR/2011/WD-html5-20110113/video.html#attr-media-controls

In my experience this feature is interfering with the page's normal rendering.

I propose the following solution:

  • Firefox starts to respect the disablePictureInPicture attribute (even if it belongs to a different spec, it seems appropriate)
  • On a page where disablePictureInPicture is set, Firefox has a non-obtrusive prompt: 'This page has disabled PiP, would you like to override?'
  • User can choose to override for 'this website', for all websites etc.

I'd love to hear your thoughts on this!

Hi cantgetright82! I'm not from Firefox but I don't believe a prompt would be part of a solution, but rather a sub optimal compromise. I believe that the solution is for Firefox to just respect disablePictureInPicture. I have no problem with it giving the user in Advanced Settings the choice to ignore the attribute for all sites or sites of their choosing. However, I don't think such a prompt can be non-obtrusive (besides the fact that it's not the "page" that would disable PiP, it's individual video elements, of which there could be multiple).

This whole discussion takes me back to when Firefox was actually saving us from non-standard stuff and weird hacks.

Picture-In-Picture is not a standard (yet). That's the problem. If you go to https://www.w3.org/TR/picture-in-picture/, you'll see it's a "Working Draft." It's not a final spec. But Chrome implemented it anyway.

Our Picture-in-Picture support was implemented independent of the spec and has none of the APIs or attributes that the spec has.

If we just support disablePictureInPicture, then when YouTube puts it behind a paywall or Twitch turns it on because they hate PiP, everyone will complain that Firefox isn't respecting the user's choice and wish that we had a way to override it.

This isn't just a simple "support the attribute". It's more nuanced. Especially since we don't have the API that would allow sites to create their own Picture-in-Picture button if they don't want ours.

We're investigating a solution, that's all I can say.

Flags: needinfo?(mconley)
Flags: needinfo?(a.stevenson82)

(In reply to Mike Kaply [:mkaply] from comment #47)

This whole discussion takes me back to when Firefox was actually saving us from non-standard stuff and weird hacks.

Picture-In-Picture is not a standard (yet). That's the problem. If you go to https://www.w3.org/TR/picture-in-picture/, you'll see it's a "Working Draft." It's not a final spec. But Chrome implemented it anyway.

Our Picture-in-Picture support was implemented independent of the spec and has none of the APIs or attributes that the spec has.

If we just support disablePictureInPicture, then when YouTube puts it behind a paywall or Twitch turns it on because they hate PiP, everyone will complain that Firefox isn't respecting the user's choice and wish that we had a way to override it.

This isn't just a simple "support the attribute". It's more nuanced. Especially since we don't have the API that would allow sites to create their own Picture-in-Picture button if they don't want ours.

We're investigating a solution, that's all I can say.

With all do respect, I understand that it it more nuanced. However:

  • PiP only being a Working Draft should not prevent you from fixing the issue people are having. (or why else does Firefox already have something similar)
  • The spec of the video element (that is not in Working Draft) says: 'should not interfere with the page's normal rendering'. The current behaviour is in violation of that.
  • If any party decides to turn it off for all video's, a simple user-setting could override it. At the moment this feature is actually breaking stuff in favour of giving "freedom" for an issue that does not yet exist.
  • If YouTube does decide to have the pay wall, they might forbid Firefox users entirely (a move that is seems a go-to for software that is broken because of this)

Good to hear you are working on a solution, I hope you take this into consideration. That's all I can say.

(In reply to Mike Kaply [:mkaply] from comment #47)

This whole discussion takes me back to when Firefox was actually saving us from non-standard stuff and weird hacks.

Picture-In-Picture is not a standard (yet). That's the problem. If you go to https://www.w3.org/TR/picture-in-picture/, you'll see it's a "Working Draft." It's not a final spec. But Chrome implemented it anyway.

Our Picture-in-Picture support was implemented independent of the spec and has none of the APIs or attributes that the spec has.

If we just support disablePictureInPicture, then when YouTube puts it behind a paywall or Twitch turns it on because they hate PiP, everyone will complain that Firefox isn't respecting the user's choice and wish that we had a way to override it.

This isn't just a simple "support the attribute". It's more nuanced. Especially since we don't have the API that would allow sites to create their own Picture-in-Picture button if they don't want ours.

We're investigating a solution, that's all I can say.

Hi Mike,

Once again, thank you for looking into this.

As I understand it, Mozilla built this feature into Firefox on their own, independent of the W3C working draft spec. Meanwhile, Google (in the spirit of working with others) implemented the PiP-feature in Chrome based on the working draft.

It seems to me that going it alone and implementing your own spec is counter productive to the proliferation of web standards and actually leads us back down the rabbit hole of browser quirks we so detested during the early 2000's.

I strongly believe that it would be in the best interest of Mozilla and the entire dev community if you just worked with the World Wide Web Consortium to draft the PiP spec to an agreeable API and implement your feature in a future-proof manner instead of acting like isolationists separate from the community. If that is happening behind-the-scenes, then great. I'm not sure why "we're investigating a solution" is all you say, but I hope it means you are considering a reimplementation to match the spec and join the community.

Team work makes the dream work! 👍

Mozilla implemented a consumer/user feature - add PiP to any video on the web.

Google implemented an API that sites could choose to use to implement picture in picture.

Yes, you can theoretically get to it on Youtube if you know the secret for displaying the native context menu, but most sites have no ability to do Picture-in-Picture unless you install a third party extension. And I would bet those third party extension don't honor disablePictureInPicture.

So Chrome does not have Picture-in-Picture. It has an API.

I honestly don't understand why the user choice is so important regarding PiP. But let's assume it really is. For me at least all arguments about it are secondary when comparing it with "it's breaking functionality implemented with standards compliant code".

(In reply to Mike Kaply [:mkaply] from comment #50)

Mozilla implemented a consumer/user feature - add PiP to any video on the web.

Google implemented an API that sites could choose to use to implement picture in picture.

Yes, you can theoretically get to it on Youtube if you know the secret for displaying the native context menu, but most sites have no ability to do Picture-in-Picture unless you install a third party extension. And I would bet those third party extension don't honor disablePictureInPicture.

So Chrome does not have Picture-in-Picture. It has an API.

Great! It sounds like Google followed spec and implemented a non-obtrusive PiP feature that allows developers to choose whether to interact with the built-in PiP window (as of Chrome 70).

I'm still not entirely sure why honouring the attribute would be such a bad idea. Drawing a parralel with plugins is not really fair, it is one thing to tell the end-user to disable a plugin, another to use a different browser entirely. Not having a solution would either force developers to drop Firefox support in some cases, or have weird hacks that could hurt performance. This discussion is all about keeping Firefox on board.

Clearly there are people hurt by this feature so some sort of fix would be nice.

From a developers perspective I see the following chain of events:

  1. Firefox has a usable <video/> element
  2. Firefox adds PiP that makes the <video/> element unusable in some situations
  3. Chrome comes with related tech, that respects that sometimes such a PiP-feature could be destructive for UX

The easiest would be to not show the button if 'disablePictureInPicture' is present. I think 99% of sites would just leave the PiP-button because there is no issue with the general use case. From the 1% of sites that would disable it, most of it would be because there is an actual issue with it. Other cases (like having a pay-wall to remove it) could then be solved by having an override in user-settings.

Why is this WONTFIX? Shouldn't this be a duplicate of #1463402 ? Can anyone explain?

This bug was specifically about supporting that attribute not the entire spec.

Duplicate of this bug: 1856478

I'm duping this over to the bug where we did add some basic support for this attribute so folks realize that we did this.

Duplicate of bug: 1811321
Resolution: WONTFIX → DUPLICATE
You need to log in before you can comment on or make changes to this bug.