User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0

Steps to reproduce:

Run firefox with MOZ_ENABLE_WAYLAND=1
Open any video in PIP mode and switch tab or window.

Using Firefox 75 beta and Gnome GNOME 3.35.91, have seen the same issue with Gnome 3.34 and Firefox 73.

Actual results:

PIP video is being put to background.

Expected results:

PIP video stays in foreground.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Looks like the gtk-shell protocol has an always-on-top feature, I wonder if gtk offers an easy API for using that l

https://gitlab.gnome.org/GNOME/gtk/commit/b3cffb8

A workaround is to right-click and set it to "Always on top". I doubt that there is a public API for that - it's basically an anti-feature for sandboxed environments.

On a short chat on IRC, other GS devs suggested to have a protocol for this - so we have a dedicated surface role for it, being subject to certain limitations.

(In reply to Robert Mader [:rmader] from comment #4)

On a short chat on IRC, other GS devs suggested to have a protocol for this - so we have a dedicated surface role for it, being subject to certain limitations.

They already have a request name="set_always_on_top" in gtk-shell.. but I would like to see a small protocol everyone would agree on, which would end up included in wayland-protocols.

err, sorry for the confusion, looks like gtk_shell's always-on-top stuff was removed ages ago. Looks like we'll need a new protocol indeed.

Problem is still present with Ubuntu 21.04 when using Wayland, not present when using Xorg. My kid enjoys watching Youtube videos as background entertainment while playing Minecraft in the foreground and is rather unhappy about this.

It was committed but then reverted:
https://mail.gnome.org/archives/commits-list/2013-October/msg09365.html

Robert, do you know any background info here? Can we actually use the gtk_shell protocol here or do I understand correctly that always-on-top was removed from gtk_shell extension?

(In reply to Martin Stránský [:stransky] (ni? me) from comment #14)

Robert, do you know any background info here? Can we actually use the gtk_shell protocol here or do I understand correctly that always-on-top was removed from gtk_shell extension?

Yeah it was removed. Users can still manually set windows as always-on-top via super+right-click, but there's currently no way for applications to do that on their own, in part because it has security implications.

The last time I chatted with some people about it there was the idea to have a dedicated Wayland protocol. I could also think of having a portal with some kind of permission management. Someone would need to come up with a decent proposal - but there's always bigger fish :(

Hi there!

Do we know if super + right-click as a way of setting a window as Always on top is common-knowledge among Ubuntu/GNOME users? Maybe it's not so well-known... I've been a (heavy) Ubuntu user for some years now and I've never heard about it.

On the other hand, since version 21.04 Ubuntu has switched its default display server to Wayland, so this problem/lack in PIP is more noticeable than before, I think. Is there any way of pushing this issue with the people in charge (of the protocol or GKT)?

(In reply to Santiago Fernández Núñez from comment #16)

Hi there!

Do we know if super + right-click as a way of setting a window as Always on top is common-knowledge among Ubuntu/GNOME users? Maybe it's not so well-known... I've been a (heavy) Ubuntu user for some years now and I've never heard about it.

On the other hand, since version 21.04 Ubuntu has switched its default display server to Wayland, so this problem/lack in PIP is more noticeable than before, I think. Is there any way of pushing this issue with the people in charge (of the protocol or GKT)?

That won't be fixed on Wayland/Gtk side - it's a security feature of Wayland itself. What we can do is to inform user how to enable Always on top feature in Wayland.

We can add an icon to PIP window which will open a window manager menu (the same as it's opened after right click). Mike, what do you think?

Hm. So what I'm hearing is that Wayland/GTK are moving to a model where applications are no longer able to request always-on-top windows, and that the user must invoke that capability, right?

I'm curious - what do other applications that have always-on-top windows do in this situation? Chromium has a picture-in-picture feature. What happens for them?

(In reply to Mike Conley (:mconley) (:⚙️) from comment #18)

Hm. So what I'm hearing is that Wayland/GTK are moving to a model where applications are no longer able to request always-on-top windows, and that the user must invoke that capability, right?

Yes, that correct. User needs to ask window manager to place the window on top, application itself can't do that. But we can open a window manager menu (we use right mouse click but we can also use an icon for that) where user can select it.

I'm curious - what do other applications that have always-on-top windows do in this situation?

Nothing - that feature is disabled on system level and any application can't enable it.

Chromium has a picture-in-picture feature. What happens for them?

Chromium / Chrome does not run under Wayland yet, they use X11 where it still works.

I think I'm going to have to defer a decision on what to do here to the PiP project manager rtestard.

Romain: it seems that, on Linux GTK, we're converging on a Wayland-powered world where applications can no longer independently create always-on-top windows like the Picture-in-Picture player window. Users can do this by right-clicking on any window and making it always-on-top, but applications don't have the ability to do this for them.

stransky has offered a solution where upon opening up a Picture-in-Picture player window when in this situation, that we also open up the native window manager menu on that player window to allow the user to then make it always-on-top.

I'm honestly not sure what other options there are than that, other than offering messaging to the user giving instructions, or disabling the feature on Wayland-backed GTK Linux altogether. What are your thoughts?

(In reply to Mike Conley (:mconley) (:⚙️) from comment #20)

stransky has offered a solution where upon opening up a Picture-in-Picture player window when in this situation, that we also open up the native window manager menu on that player window to allow the user to then make it always-on-top.

We can also open the window manager menu automatically after PIP creation to allow user select 'always on top' and 'stay on all workspaces'.

I am sorry if this is obvious for everyone else but I just tried out the Flatpak version of Firefox 90 from Flathub on Fedora 34 with Wayland and noticed that the PiP window perfectly stays in foreground very much like it did on the X11+dnf version. Like stated above however it does not work on the Wayland+dnf version of Firefox.

Both versions were 90.0.2. How come it works in the Flatpak version but not in the dnf installed version? That at least gives hope for Wayland support right?

Also in the Wayland+dnf version, when I fold out the PiP, I noticed heavy glitching in the original frame of the youtube video (which should be black but parts of the video glitch into it from time to time).

(In reply to Martin Stránský [:stransky] (ni? me) from comment #21)

(In reply to Mike Conley (:mconley) (:⚙️) from comment #20)

stransky has offered a solution where upon opening up a Picture-in-Picture player window when in this situation, that we also open up the native window manager menu on that player window to allow the user to then make it always-on-top.

We can also open the window manager menu automatically after PIP creation to allow user select 'always on top' and 'stay on all workspaces'.

Hello, apologies for the delay here, any chance you could give a screenshot of that menu since I don't have the right environment to replicate?
Also I read through https://www.reddit.com/r/kde/comments/osjt3p/firefox_wayland_pip_workaround_or_how_i_learned/ - I assume there is no way to have these settings by Firefox?

(In reply to Romain Testard [:RT] from comment #24)

(In reply to Martin Stránský [:stransky] (ni? me) from comment #21)

(In reply to Mike Conley (:mconley) (:⚙️) from comment #20)

stransky has offered a solution where upon opening up a Picture-in-Picture player window when in this situation, that we also open up the native window manager menu on that player window to allow the user to then make it always-on-top.

We can also open the window manager menu automatically after PIP creation to allow user select 'always on top' and 'stay on all workspaces'.

Hello, apologies for the delay here, any chance you could give a screenshot of that menu since I don't have the right environment to replicate?

Will do so.

Also I read through https://www.reddit.com/r/kde/comments/osjt3p/firefox_wayland_pip_workaround_or_how_i_learned/ - I assume there is no way to have these settings by Firefox?

That's a good questions. I guess KDE may ship that on distro level but AFAIK Gnome does not support it by default.

This menu is opened by window manager after right mouse click and we can choose where it's placed. We can also open it automatically after PIP creation or add an icon for it.

(In reply to Martin Stránský [:stransky] (ni? me) from comment #25)

(In reply to Romain Testard [:RT] from comment #24)

(In reply to Martin Stránský [:stransky] (ni? me) from comment #21)

(In reply to Mike Conley (:mconley) (:⚙️) from comment #20)

stransky has offered a solution where upon opening up a Picture-in-Picture player window when in this situation, that we also open up the native window manager menu on that player window to allow the user to then make it always-on-top.

We can also open the window manager menu automatically after PIP creation to allow user select 'always on top' and 'stay on all workspaces'.

Hello, apologies for the delay here, any chance you could give a screenshot of that menu since I don't have the right environment to replicate?

Will do so.

Also I read through https://www.reddit.com/r/kde/comments/osjt3p/firefox_wayland_pip_workaround_or_how_i_learned/ - I assume there is no way to have these settings by Firefox?

That's a good questions. I guess KDE may ship that on distro level but AFAIK Gnome does not support it by default.

Thanks. And there is no way Firefox could set this value as part of the installation process to ensure Firefox PiP remains always on top? I don't know if something similar to Windows registry values can be set on Linux and if this is accessible by third party apps, if there is a possibility it seems like the ideal way to do it.

Perhaps https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/28

But it seems like GNOME has no plans to support it: https://gitlab.gnome.org/GNOME/mutter/-/issues/316#note_671694

(In reply to Teoh Han Hui from comment #28)

Perhaps https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/28

But it seems like GNOME has no plans to support it: https://gitlab.gnome.org/GNOME/mutter/-/issues/316#note_671694

layer-shell is designed for desktop elements, it is intended as a privileged protocol and so should not be used for PiP.

We need to get everyone to agree on a PiP protocol specifically, with the appropriate restrictions and simple interface.

layer-shell is designed for desktop elements, it is intended as a privileged protocol and so should not be used for PiP.

We need to get everyone to agree on a PiP protocol specifically, with the appropriate restrictions and simple interface.

I guess we shouldn't discuss this here as it's going off-topic. Opened https://github.com/flatpak/xdg-desktop-portal/issues/612

(In reply to Romain Testard [:RT] from comment #27)

Thanks. And there is no way Firefox could set this value as part of the installation process to ensure Firefox PiP remains always on top? I don't know if something similar to Windows registry values can be set on Linux and if this is accessible by third party apps, if there is a possibility it seems like the ideal way to do it.

This is a part of Wayland architecture/security design that any application can't set itself on top of other ones or position itself on the desktop. So no, Firefox itself can't do that in any way right now. Also note that the menu is opened by window manager, not by Firefox - we just ask window manager to open it for us for a particular window but it can't be 'clicked' from Firefox side.

There's now an attempt to make a dedicated protocol for this: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/132

There's a GNOME extension called PiP on top that gets around this Wayland limitation with specific support for Firefox.

The severity field for this bug is relatively low, S3. However, the bug has 9 duplicates.
:stransky, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Updated, but we can't fix that unless it's addressed by Wayland compositors:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/44

The upstream issue is somewhat idle right now, and I believe part of the reason is the hesitance to allow input/output PiP surfaces, as they would be trivially abused as very intrusive arbitrary dialogs. Would output only PiP work for Firefox?

In other words, a pip window would not receive input events like pointer events, keyboard keys and touch points, but instead get high level "play/pause/forward/backward/close/..." like events depending on how the PiP window is setup. This appears to be how it behaves, with some level of variation, on various mobile platforms right now, I believe.

Naive question: Does comment 42 basically mean to extend MPRIS (media.hardwaremediakeys.enabled: bug 1353652, https://wiki.archlinux.org/title/MPRIS) in a way that you give it a surface/window/"title of a window" as a video source, so that Gnome etc. can make their own PiP window out of it with MPRIS play/pause controls or something in that direction? That doesn't sound bad IMHO.

(In reply to Darkspirit from comment #43)

Naive question: Does comment 42 basically mean to extend MPRIS (media.hardwaremediakeys.enabled: bug 1353652, https://wiki.archlinux.org/title/MPRIS) in a way that you give it a surface/window/"title of a window" as a video source, so that Gnome etc. can make their own PiP window out of it with MPRIS play/pause controls or something in that direction? That doesn't sound bad IMHO.

That's an open question. I mentioned such an idea here, but whether that'll be how things are done is a different story. In one way or the other, it'd mean media controls would be drawn by the compositor, not by Firefox itself, as it does now on Linux.

ould output only PiP work for Firefox?

IMO, no. PiP in Firefox has a number of controls (and soon more controls!) that allow the user to control the originating video. Those controls include playing, pausing, muting. Some form of subtitle control is likely to be added in the near future, and we're also investigating seeking. These controls are buttons that the user can interact with with both the mouse and keyboard, and assumes that the underlying window can receive user input events.

(In reply to Mike Conley (:mconley) (:⚙️) from comment #45)

ould output only PiP work for Firefox?

IMO, no. PiP in Firefox has a number of controls (and soon more controls!) that allow the user to control the originating video. Those controls include playing, pausing, muting. Some form of subtitle control is likely to be added in the near future, and we're also investigating seeking. These controls are buttons that the user can interact with with both the mouse and keyboard, and assumes that the underlying window can receive user input events.

How is this intended to work on platforms where input/output PiP windows aren't possible, meaning, if I'm understanding things correctly, at least Android?

Firefox for Android uses a completely separate codepath / mechanism for Picture-in-Picture. Specifically, it offloads it to the OS's built-in Picture-in-Picture mechanism.

(In reply to Mike Conley (:mconley) (:⚙️) from comment #47)

Firefox for Android uses a completely separate codepath / mechanism for Picture-in-Picture. Specifically, it offloads it to the OS's built-in Picture-in-Picture mechanism.

That is how it'd have to work if PiP in Wayland were to be output only. Is that an option, and if so, what exactly would be needed, feature wise?

what exactly would be needed, feature wise?

I think we would want to be able to offer the same experience to users on Wayland as users on Windows or macOS - so a way of describing similar controls, and hearing about when they're used.

To be clear, this is also a reason why we don't use the native OS Picture-in-Picture capability on macOS: the API does not give us the ability to put in our own controls.

There's now an attempt to make a dedicated protocol for this: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/132

The upstream issue is somewhat idle right now

In an attempt to un-idle it I have created a GTK lib; based on gtk-layer-shell and relevant firefox patches:

https://github.com/davidedmundson/gtk-pip-shell

A few lines later in firefox I did get everything working nicely. The final firefox code is relatively small. Little more than:

widget/gtk/nsWindow.cpp:
+  if (mIsPIPWindow) {
+    gtk_pip_init_for_window(GTK_WINDOW(mShell));
+  }

I can submit that into a proper patch, but there's one big shadow hanging over this.

The way gtk-layer-shell (which I forked into gtk-pip-shell) works with GTK3 is sketchy as best using private headers. Supposedly there's a magic solution coming in some future GTK4 , but that doesn't help us.

Turning this into a question, would use of an optional extra lib doing that be a direction that could get accepted?

Note that there is no consensus in https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/132 whether PiP windows are to be allowed arbitrary input (effectively making them always-on-top dialogs, which can be a relatively harmful concept that applications tend to abuse on X11), or make them more like PiP windows an Android/iOS which do not allow arbitrary input.

I am moving forward with a version that has input.

(In reply to David Edmundson from comment #50)

Turning this into a question, would use of an optional extra lib doing that be a direction that could get accepted?

Probably not the one that would end up making the call, but FWIW that seems a reasonable path forward to me.

(In reply to David Edmundson from comment #52)

I am moving forward with a version that has input.

Please don't make the assumption that it will be how PiP works on Wayland without it having been the conclusion upstream. Experimenting is not problematic of course, assuming it's done with the assumption that changes to how a PiP window is interacted with will change significantly before anything ends up in a landable state.

Don't know if this can help but PiP windows do stay on top on Ubuntu 23.04 on Wayland.

Xwayland is not Wayland.