Note

• When the user ..., he will notice that...

Affected versions

• Nightly v96.0a1

Affected platforms

• Ubuntu 21 + Wayland

Steps to reproduce

1. Go into the "nightly" folder
2. Right-click and "Open in Terminal"
3. type: MOZ_ENABLE_WAYLAND=1
4. And then: ./firefox
5. Load https://emilghitta.github.io/TestPages/TestCases/ShareScreen.html
6. Click on "Start Capture"
7. Click the drop-down and select the Nightly Window.

Expected result

• The Nightly window is in the list and correctly selected.

Actual result

• The nightly window is not an option in the drop-down.

Regression range

• unknown

Additional notes

• This issue only occurs with wayland, not with xwayland or x11 Window Protocols.

Confirmed, we don't use the portal any more. Most likely fallout from bug 1654112

Set release status flags based on info from the regressing bug 1654112

It's because we don't build pipewire support at all. WEBRTC_USE_PIPEWIRE is not set.

Andreas, how I can re-generate the makefiles from gn to tweak the changes?
Thanks.

src/third_party/libwebrtc/modules/desktop_capture/desktop_capture_generic_gn/moz.build is missing the WEBRTC_USE_PIPEWIRE define which was there before.

I tried to follow https://firefox-source-docs.mozilla.org/build/buildsystem/gn.html
but I got:

./mach build-backend -b GnConfigGen
0:00.55 /raid/src/objdir/_virtualenvs/build/bin/python /raid/src/objdir/config.status --backend GnConfigGen
Reticulating splines...
0:00.37 File already read. Skipping: /raid/src/intl/components/moz.build
0:00.59 File already read. Skipping: /raid/src/gfx/angle/targets/angle_common/moz.build
Running "/usr/bin/gn gen /raid/src/objdir/dom/media/webrtc/third_party_build/../../../../third_party/libwebrtc/gn-output --args=is_debug=true target_os="linux" host_cpu="x64" target_cpu="x64" --ide=json"
ERROR at //build/config/BUILDCONFIG.gn:310:1: Unknown function.
set_sources_assignment_filter(sources_assignment_filter)
^----------------------------
Traceback (most recent call last):
File "/raid/src/objdir/config.status", line 1047, in <module>
config_status(**args)
File "/raid/src/python/mozbuild/mozbuild/config_status.py", line 177, in config_status
the_backend.consume(definitions)
File "/raid/src/python/mozbuild/mozbuild/backend/base.py", line 132, in consume
if not self.consume_object(obj) and not isinstance(self, PartialBackend):
File "/raid/src/python/mozbuild/mozbuild/gn_processor.py", line 609, in consume_object
generate_gn_config(
File "/raid/src/python/mozbuild/mozbuild/gn_processor.py", line 582, in generate_gn_config
subprocess.check_call(gen_args, cwd=srcdir, stderr=subprocess.STDOUT)
File "/usr/lib64/python3.9/subprocess.py", line 373, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['/usr/bin/gn', 'gen', '/raid/src/objdir/dom/media/webrtc/third_party_build/../../../../third_party/libwebrtc/gn-output', '--args=is_debug=true target_os="linux" host_cpu="x64" target_cpu="x64"', '--ide=json']' returned non-zero exit status 1.

Michael knows this better, plus I'll be mostly unavailable for a few days.

Martin, sorry for the delay. In general, with the new libwebrtc update, the steps here are what we follow when updating moz.build files.

try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f9ae2568fbc0a128f292fe2a175725b91153dd21

I tested the change to third_party/libwebrtc/webrtc.gni for generating on macOS and win and don't see any unintended changes to the moz.build files.

https://hg.mozilla.org/mozilla-central/rev/25a9cc62f10b

Reminder to verify.

The original issue no longer reproduces on the original system because the user is now able to share the Firefox/Nightly window, but the whole UX has changed and it became a little confusing.

Test Results:

1. The system it was first discovered on: desktop + U21.10 + AMD 8core + NVidia GT 710 (NV106 driver)

When opening the browser with wayland OR EVEN xwayland Window Protocol, then go into a WebRTC app/testcase and click the Screen Sharing button, the user will see the Screenshare Permission Doorhanger, but won't be able to open the drop-down which is having the default selection of "Use operating system settings". Upon clicking the "Allow" button, the Global Sharing Overlay gets displayed and a System pop-up window will be displayed; it can be used to select what he would like to share (window/entire screen).
Issue here: The screen share functionality can be used, but the original UX of this procedure has changed.

2. High end laptop + U20.04.3 + i7 + integrated Intel UHD Graphics 630 (dedicated NVidia GTX not recognized in Ubuntu)

2.1 When opening the browser with wayland OR EVEN xwayland Window Protocol, then go into a WebRTC app/testcase and click the Screen Sharing button, the user will see the Screenshare Permission Doorhanger, but he won't be able to open the drop-down which is having the default selection of "Use operating system settings". Upon clicking the "Allow" button, the Global Sharing Overlay gets displayed and a System's pop-up window will NOT be shown, the screen-share will not work, however, the Global Sharing overlay will be displayed.
The issue here: The system's screen share selection window is not being displayed.

2.2 When opening the browser with x11 Window Protocol, then go into a WebRTC app/testcase and click the Screen Sharing button, the user will see the Screenshare Permission Doorhanger, and he is able to open the drop-down (while working around a new issue) and select the nightly window and share it.
The issue here: the drop-down on the Screen Sharing Permission Door Hanger can be opened, but the options that are being displayed over the door-hanger frame can not be selected using the cursor; Workaround: use keyboard navigation.

3. Low-end laptop +U20.04.3 + i3 + Intel HD Graphics 5500

3.1 When opening the browser with wayland OR EVEN xwayland Window Protocol, then go into a WebRTC app/testcase and click the Screen Sharing button, the user will see the Screenshare Permission Doorhanger, but he won't be able to open the drop-down which is having the default selection of "Use operating system settings". Upon clicking the "Allow" button, the Global Sharing Overlay gets displayed but a System's pop-up window will NOT be shown, the screen share will not work.
The issue here: The system's screen share selection window is not being displayed.

3.2 When opening the browser with X11 Window Protocol, then go into a WebRTC app/testcase and click the Screen Sharing button, the user will see the Screenshare Permission Doorhanger and he is able to open the drop-down (while working around a new issue) and select the nightly window and share it.
The issue here: the drop-down on the Screen Sharing Permission Door Hanger can be opened, but the options that are being displayed over the door-hanger frame can not be selected using the cursor; Workaround: use keyboard navigation.

Note 1: the test case link has changed to: https://emilghitta.github.io/TestPages/TestCases/ScreenShare/ShareScreen.html
Note 2: These tests were performed with both Nightly v97.0a1 and Release v95.0. The results are the same.
Note 3: Other info from the wild: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1915802

In conclusion, this bug is partially fixed because it caused other issues:

1. UX change. Is it intended?
2. On some systems with wayland/xwayland, the system's screen share selection window is not being displayed.
3. On systems with X11, the drop-down on the Screen Sharing Permission Door Hanger can be opened, but the options that are being displayed over the door-hanger frame can not be selected using the cursor; Workaround: use keyboard navigation.

These bugs will be logged when running the next wayland nightly validation run, next week. Leaving the NeedInfo as a reminder.

Martin, how do you think we should address this bug? Am I missing any important test areas?

(In reply to Bodea Daniel [:danibodea] from comment #16)

In conclusion, this bug is partially fixed because it caused other issues:

1. UX change. Is it intended?

Yes, it's the best we made up here. The "Use operating system settings" dialog is shown to identify which tab wants to share screen. It may be replaced with something better for sure but we need something to notify user which tab requests that.

2. On some systems with wayland/xwayland, the system's screen share selection window is not being displayed.

That's a bug on OS level. Can you try different application which shares screen. There's a bug that we pretend the screen is shared although sharing was disabled on OS level (Bug 1678269).

3. On systems with X11, the drop-down on the Screen Sharing Permission Door Hanger can be opened, but the options that are being displayed over the door-hanger frame can not be selected using the cursor; Workaround: use keyboard navigation.

I'm not aware of any change in X11 screen sharing UI, is that a recent regression?

Could the X11 bug be bug 1745551?

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

(In reply to Bodea Daniel [:danibodea] from comment #16)

In conclusion, this bug is partially fixed because it caused other issues:

1. UX change. Is it intended?

Yes, it's the best we made up here. The "Use operating system settings" dialog is shown to identify which tab wants to share the screen. It may be replaced with something better for sure but we need something to notify users which tab requests that.

I'll assume this is a temporary workaround as it is not a clear/elegant process.

2. On some systems with wayland/xwayland, the system's screen share selection window is not being displayed.

That's a bug on OS level. Can you try different application which shares screen. There's a bug that we pretend the screen is shared although sharing was disabled on OS level (Bug 1678269).

I've tested this with other WebRTC applications like whereby.com, Facebook.com, talky.io, but they all behave the same. The system UI/modal window does not appear and the user is not able to choose what he wants to share. Furthermore, it appears as it's already sharing.

According to https://help.ubuntu.com/stable/ubuntu-help/sharing-desktop.html.en, the sharing needs to be activated from OS settings, however, it appears that my system has it deactivated by default. This should probably be taken into consideration. It is unknown why it's deactivated as this is a default installation of Ubuntu 20.04.3 LTS.

Furthermore, according to https://linuxhint.com/enable-screen-sharing-ubuntu/, it can be activated by installing vivo and then activating it from the OS Sharing settings, but it didn't work. Moreover, the desktop system that allows this window to be shown has its sharing disabled on OS level, just like the affected laptop. The difference I see is that the desktop has a Screen Sharing option displayed in the Sharing panel (even if disabled), while the laptop does not. The only rule I see is that the desktop works while the laptops do not.

From my point of view, I need information on how an Ubuntu should have its settings by default in order to share the screen over web applications. I would need to know how to properly set any/every Ubuntu system I have in order to test this properly. What do you think?

3. On systems with X11, the drop-down on the Screen Sharing Permission Door Hanger can be opened, but the options that are being displayed over the door-hanger frame can not be selected using the cursor; Workaround: use keyboard navigation.

I'm not aware of any change in X11 screen sharing UI, is that a recent regression?
Yes, the issue appears to be the same as bug 1745551 and it is fixed in Nightly v97.0a1 from 2021-12-14.

(In reply to Bodea Daniel [:danibodea] from comment #19)

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

(In reply to Bodea Daniel [:danibodea] from comment #16)

In conclusion, this bug is partially fixed because it caused other issues:

1. UX change. Is it intended?

Yes, it's the best we made up here. The "Use operating system settings" dialog is shown to identify which tab wants to share the screen. It may be replaced with something better for sure but we need something to notify users which tab requests that.

I'll assume this is a temporary workaround as it is not a clear/elegant process.

That's the best I managed to do here. Feel free to file a new bug and submit patches for it.

2. On some systems with wayland/xwayland, the system's screen share selection window is not being displayed.

That's a bug on OS level. Can you try different application which shares screen. There's a bug that we pretend the screen is shared although sharing was disabled on OS level (Bug 1678269).

I've tested this with other WebRTC applications like whereby.com, Facebook.com, talky.io, but they all behave the same. The system UI/modal window does not appear and the user is not able to choose what he wants to share. Furthermore, it appears as it's already sharing.

According to https://help.ubuntu.com/stable/ubuntu-help/sharing-desktop.html.en, the sharing needs to be activated from OS settings, however, it appears that my system has it deactivated by default. This should probably be taken into consideration. It is unknown why it's deactivated as this is a default installation of Ubuntu 20.04.3 LTS.

Furthermore, according to https://linuxhint.com/enable-screen-sharing-ubuntu/, it can be activated by installing vivo and then activating it from the OS Sharing settings, but it didn't work. Moreover, the desktop system that allows this window to be shown has its sharing disabled on OS level, just like the affected laptop. The difference I see is that the desktop has a Screen Sharing option displayed in the Sharing panel (even if disabled), while the laptop does not. The only rule I see is that the desktop works while the laptops do not.

From my point of view, I need information on how an Ubuntu should have its settings by default in order to share the screen over web applications. I would need to know how to properly set any/every Ubuntu system I have in order to test this properly. What do you think?

That seems to be Ubuntu specific bug, maybe related to Snap sandbox? Can you test Mozilla binaries there? I don't see that on Fedora.