Closed Bug 1628431 Opened 4 years ago Closed 10 months ago

Firefox Sharing Indicator is shown as full-size window in Sway WM / Wayland

Categories

(Core :: Widget: Gtk, defect, P3)

Product:
Core
Component:
Widget: Gtk
Version:
75 Branch
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1668358

People

(Reporter: dschridde+mozilla, Unassigned)

References

(Blocks 1 open bug)

Details

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

Steps to reproduce:

  1. I am using Sway WM 1.4 and Firefox 75.0.
  2. I join a video meeting room on https://whereby.com/
  3. "Firefox - Sharing Indicator" shows up as a full-size window

Actual results:

"Firefox - Sharing Indicator" shows up as a full-size window.

Expected results:

On KDE Plasma / X11 the sharing indicator is shown as a tiny icon at the top of the screen instead.

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

Component: Untriaged → Widget: Gtk
Product: Firefox → Core
Blocks: wayland
Priority: -- → P3

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is P3 (Backlog,) indicating it has been triaged, the bug's Severity is being updated to S3 (normal.)

Severity: normal → S3

I can confirm that with sway/wlroots 1.5.1 and the current git masters (will become sway 1.6.0 anytime soon) and firefox developer edition. I currently run 86b7 where I have another issue which doesn't get me as far as entering the video chat but I've had that issue since I started using video chat about 2 month ago (for homeschooling purposes) with the firefox developer edition which was current at that point in time.

While waiting for a fix, I can think of some workarounds.

  1. focus on the sharing indicator window and make it floating by using the floating toggle command, the relevant Sway config entry looks like this:
    bindsym $mod+Shift+space floating toggle

  2. Make the sharing indicator window automatically floating by adding this line to your Sway config:
    for_window [title="Firefox Developer Edition - Weitergabe-Indikator"] floating enable;
    (where "title" is the exact name of the Firefox window you don't want around)
    once the window is floating you can move out of the way.

  3. If you don't want that window at all, you can close it straight away:
    for_window [title="Firefox Developer Edition - Weitergabe-Indikator"] kill;

Sway configuration documentation available with man 5 sway

hth

forgot to mention (just in case): reload sway after every change with $ swaymsg reload

Blocks: wayland-sway
No longer blocks: wayland

Why is this a bug only for Sway? Isn't it a generic wayland issue? I use KDE's Plasma, and having another window just for the permissions is a bit odd, inconvenient and inconsistent. Can't this be displayed like with X11?

(In reply to physkets from comment #6)

Why is this a bug only for Sway? Isn't it a generic wayland issue? I use KDE's Plasma, and having another window just for the permissions is a bit odd, inconvenient and inconsistent. Can't this be displayed like with X11?

Changing the visual style of the sharing indicator was tracked in bug #1705048. The result should become available in Firefox 90.

It will still be a window, but Martin mentioned another bug, that should change it into a "popup" (which I assume will have a visual style much closer to what we had on X11):

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

(In reply to devurandom from comment #9)

Thanks, Martin! Does this mean bug #1628431 is also fixed?

Please try that. The windows is still created as toplevel but it has disabled decorations. We can't create it as popup as it does not have a parent window. Bug 1703073 will have huge popup redesign and we should apply correct popup roles when it's fixed.

I'd need more info what do you exactly want to set on the window to behave correctly. Does any other application use popups/floats which behaves correctly? What attributes are set here? Do you know what makes the difference?

Are you asking me? I was hoping that the indicator could be displayed in the main Firefox window, without opening a new one. So maybe have some space re-purposed when sharing mic/screen, so that a new window doesn't have to be created.

How about an additional element/symbol in the title-bar? Is that too unnoticeable?

(In reply to physkets from comment #9)

Are you asking me? I was hoping that the indicator could be displayed in the main Firefox window, without opening a new one. So maybe have some space re-purposed when sharing mic/screen, so that a new window doesn't have to be created.

How about an additional element/symbol in the title-bar? Is that too unnoticeable?

I can only change how the indicator window is displayed, i.e. change window type to make it floating or so. To remove it completely or create it as a part of FF main window you need to report it against Firefox / WebRTC component and that would be completely different task.

Maybe a bit off topic, but now you are speaking about window types: I use GNOME on Wayland. The little window with the Firefox, camera, and microphone window looks good to me, although one could argue that it duplicates the icons in the tab. But this small window is not always on top (of the other Firefox window(s), or maybe even all windows) so it disappears quickly behind other windows, which kind of takes away the purpose of this small alert window. So, maybe it should be always on top. IIRC it is always on top in Xorg, and always in a fixed position at the top in the middle of the screen as well. Please, let me know if you prefer a separate bug for this.

On Wayland we can't position any window or put it on top.

Same problem with GNOME + Pop Shell (window tiling extension) on Wayland. The sharing indicator takes up 50% of the display, the main Firefox window the other half. This behaviour is different from other pop-up windows created by Firefox (e.g., Print, Save Page As, and so on). Those other pop-up windows are shown as a floating window above the main Firefox window. I do not know the technical details, but it would be very nice if the sharing indicator window would be treated the same as the other pop-up windows I mentioned.

Workaround (do not show the Sharing Indicator): in about:config set privacy.webrtc.legacyGlobalIndicator to False.

Does the new indicator work properly? If so we may use the same setup for the old one.

Flags: needinfo?(rhubinak)

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

Does the new indicator work properly? If so we may use the same setup for the old one.

I am not the issue reporter but as of Firefox on Linux 93.0b9 and Sway 1.6 I still experience the reported behaviour. I'm using the suggested workaround in comment #4

As a knock-on effect, when a website starts webrtc, it causes a window blur event that is not expected, and occasionally has catastrophic results. Rosetta stone pauses webrtc as soon as the window defocusses. This causes an infinite start webrtc, blur, stop webrtc, focus loop. Rosetta stone becomes unusable at that point.

(In reply to physkets from comment #6)

Why is this a bug only for Sway? Isn't it a generic wayland issue? I use KDE's Plasma, and having another window just for the permissions is a bit odd, inconvenient and inconsistent. Can't this be displayed like with X11?

It is only for tiling window managers like sway that the misclassification of the window as tiling rather than floating is noticeable.

Still reproducible for me on wayland, KDE. Mic and other icons exist as one more usual little window. Firefox is set to use Wayland mode via export MOZ_ENABLE_WAYLAND=1, and I checked Window Protocol wayland in Firefox.

Firefox 106.0 from Debian SID repo.
Operating System: Debian GNU/Linux Testing (Bookworm)
KDE Plasma Version: 5.26.0
KDE Frameworks Version: 5.98.0
Qt Version: 5.15.4
Kernel Version: 5.19.0-2-amd64 (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 5800U with Radeon Graphics
Memory: 15.0 GiB of RAM
Graphics Processor: RENOIR
Manufacturer: HP
Product Name: HP Pavilion Aero Laptop 13-be0xxx

Redirect a needinfo that is pending on an inactive user to the triage owner.
:stransky, since the bug has recent activity, could you please find another way to get the information or close the bug as INCOMPLETE if it is not actionable?

For more information, please visit auto_nag documentation.

Flags: needinfo?(rhubinak) → needinfo?(stransky)

(In reply to gmelikov from comment #20)

Still reproducible for me on wayland, KDE. Mic and other icons exist as one more usual little window. Firefox is set to use Wayland mode via export MOZ_ENABLE_WAYLAND=1, and I checked Window Protocol wayland in Firefox.

Firefox 106.0 from Debian SID repo.
Operating System: Debian GNU/Linux Testing (Bookworm)
KDE Plasma Version: 5.26.0
KDE Frameworks Version: 5.98.0
Qt Version: 5.15.4
Kernel Version: 5.19.0-2-amd64 (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 5800U with Radeon Graphics
Memory: 15.0 GiB of RAM
Graphics Processor: RENOIR
Manufacturer: HP
Product Name: HP Pavilion Aero Laptop 13-be0xxx

Example screenshot: https://postimg.cc/9rhznz9t

Flags: needinfo?(stransky)

Behaviour still present on FF 107 and sway 1.7.

Also reproduced on Gnome when using export MOZ_ENABLE_WAYLAND=1.
Instead of having the indicator shown atop every Firefox windows, it appears with its distinct window to a different place than on XWayland (that can be alt-tabbed or equivalent). It just doesn't have window decorations as compared to the screenshot on KDE that have them.

Also, seeing the numerous reports on various compositors, I think I can confirm the bug; feel free to undo if I shouldn't have done so.

Status: UNCONFIRMED → NEW
Ever confirmed: true

This still happens in Firefox 109 on Debian bookworm in Sway.

Also, i think making the window "floating" fixes the problem the wrong way. This notification should use standard notification area semantics and just not pop up a window at all. This is how it seems it was done in Windows, two years ago:

https://bugzilla.mozilla.org/show_bug.cgi?id=1663784

It seems to me Firefox should just behave like a normal desktop app and send its notifications using the normal notification mechanisms, not just pop open a random window and hope it's going to do the right thing...

Still present in 113.

See Also: → 1850697
See Also: → wayland-pip

We disabled the indicator on Wayland in bug 1668358. Wayland compositors always know when sharing is active and can thus show an indicator themselves, but I don't know what the current status is on Sway - a Waybar dev showed interest in implementing it though, see https://floss.social/@1ace@mastodon.gamedev.place/110754468668178972

Status: NEW → RESOLVED
Closed: 10 months ago
Duplicate of bug: 1668358
Resolution: --- → DUPLICATE

:rmader, I assume they know when screensharing is in use, but I'm not sure it's also the case for cameras and microphones, is it?

Either way, I understand it means it falls upon compositors to manage this. Is it too hard to get it working from Firefox like on Xorg? Even when the PiP issue would be solves (as I'm guessing once PiP can work correctly, this could use the exact same mechanics)?

but I'm not sure it's also the case for cameras and microphones, is it?

These are not shown any more after the last redesign of the indicator - it was only showing screen sharing.

However:

  • microphones are managed by the sound server these days (Pulseaudio/Pipewire), so DEs have been able to show their active state for years
  • cameras are a bit harder as long as V4L2 is used directly, but once the camera server (Pipewire / media.webrtc.camera.allow-pipewire) is used by default, that's possible as well. Gnome 45 will show an indicator in this case and Waybar will hopefully implement that, too (see https://floss.social/@rmader/110815436058994927 and the reply mentioned above)

Is it too hard to get it working from Firefox like on Xorg?

It's a explicit design goal to not allow clients to control their window position and do stuff like that. So the concept of the indicator is fundamentally at odds with the Wayland philosophy. IMHO that's a very good thing - privacy indicators are IMHO conceptually more a OS thing, and on mobile platforms that's been always like that. I'm looking forward to the PiP protocol though.

See Also: 1850697, wayland-pip →
You need to log in before you can comment on or make changes to this bug.