Closed Bug 1412333 Opened 7 years ago Closed 2 years ago

[Linux] Screen share selection on dual monitors - only "entire screen" option available

Categories

(Core :: WebRTC: Audio/Video, task, P2)

Product:
Core
Component:
WebRTC: Audio/Video
Platform:
All
Linux
Type:
task

Tracking

()

Status:
VERIFIED FIXED
Milestone:
98 Branch
Tracking Flags:
Tracking Status
firefox96 --- wontfix
firefox97 --- wontfix
firefox98 --- verified

People

(Reporter: aflorinescu, Assigned: pehrsons)

References

(Blocks 1 open bug)

Details

(Keywords: parity-chrome, parity-edge)

Attachments

(4 files)

Your Entire Screen
76.02 KB, image/png
Details
Bug 1412333 - Generalize DesktopDeviceInfoImpl for screen capture like what has been done for window capture. r?ng!
48 bytes, text/x-phabricator-request
Details | Review
Bug 1412333 - Remove traces of MULTI_MONITOR_SCREENSHARE. r?ng!
48 bytes, text/x-phabricator-request
Details | Review
Bug 1412333 - Update generated build files. r?ng!
48 bytes, text/x-phabricator-request
Details | Review 
[Steps:]
1. Have dual monitors and open FF.
2. Open https://jsfiddle.net/pehrsons/7kgvL48e/ ,select Video/Screen and press Start.
3. An identity panel pop-up will be shown to select the screen to share(record).
4. Select Entire screen and "Allow".

[Actual Result:]
3. The options Screen 1 / Screen 2 is missing, being replaced by "Entire screen"
4. The recording will capture and record both screens in a 3840x1080 resolution. 

[Note1:]
Please see upstream bug: https://bugs.chromium.org/p/chromium/issues/detail?id=437507.
Blocks: 1412341
jib, is this something you know of? Maybe somewhere to dupe this one?
Rank: 25
Flags: needinfo?(jib)
Priority: -- → P3
Looks like an upstream issue. Unfortunately, the upstream issue was closed as WontFix for what seems like poor reasons, judging by the subsequent activity. Maybe we should file a new bug?

Dan, any thoughts?
Flags: needinfo?(jib) → needinfo?(dminor)
Someone filed a new bug back in 2016 as https://bugs.chromium.org/p/chromium/issues/detail?id=660032 which doesn't seem to have been prioritized yet. If we want this fixed, I'm guessing the best bet would be to do the work ourselves and upstream it.

Looking at the code it seems like the relevant functions (ScreenCapturerLinux::GetSourceList and ScreenCapturerLinux::SelectSource) are just not implemented. I'm not sure offhand how much work would be involved in writing these, but I'd be willing to take a look when I have a chance, assuming we're happy with this being a P3.
Flags: needinfo?(dminor)
Assignee: nobody → dminor
I'm not sure if it's related to this bug, but I also can't select a single window to share.
Only the entire desktop is offered in the dropdown.

Browser: Firefox 58
OS: Debian buster (testing)
Architecture: amd64
Desktop: Plasma5/Xorg
Package: firefox-58.0.1-1+b1 from the Debian repos

Until this issue is fixed, here https://github.com/Ashark/hliss is good script with quick workaround for this problem to share only one screen via Firefox on Linux with multiple monitors setup.

And here https://bugs.chromium.org/p/chromium/issues/detail?id=396091 is same issue in Chromium thread.

Related patch on Chromium hasn't been reverted since a month ago this time. Let's hope it sticks!

https://bugs.chromium.org/p/chromium/issues/detail?id=396091#c74

Good news! Just tested out with the latest Chrome Dev release, it works!!!

  • Chrome Dev Versione 83.0.4093.3 (Official Build) dev (64 bit)
  • Ubuntu 18.04.1 freshly installed and updated last friday (2020-03-27)

What do we need to do to have it here? Just pull from WebRTC upstream?

Related patch on Chromium hasn't been reverted since a month ago this time. Let's hope it sticks!

Sticks to Firefox code? =)

Does same code from Chrome can be reused in Firefox, or it use different implementation?

I was talking about "sticks to Chromium code", since the patch got reverted multiple times due to downstream tests breakage ;)

I don't know Firefox's codebase, if it uses WebRTC it should just be able to use it as is pulling from upstream.

@jib? @dminor? Can you weight in here?

Flags: needinfo?(dminor)

Upstream commit is: https://webrtc.googlesource.com/src.git/+/e952b78c283f5e54376561f7c7dd1460143c6112. We should be able to cherry pick it and apply to our local copy. I'll have a look.

Flags: needinfo?(dminor)

Unfortunately, taking these changes will have to wait until we do our next import of libwebrtc.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE

Why this issue is closed with marking as duplicate of other issue, that closed too? This is not fixed, and must stay open in current issue, because it is earlier and have more detailed info!

Flags: needinfo?(dminor)

And is there any estimate date exists when next import of libwebrtc into Mozilla repo planned?

The update is being worked on in Bug 1654112. This should probably depend on that bug rather than being a duplicate of that bug, just in case the update doesn't actually fix things.

Assignee: dminor → nobody
Status: RESOLVED → REOPENED
Depends on: 1654112
Flags: needinfo?(dminor)
Resolution: DUPLICATE → ---

Screen sharing with Jitsi-Web or Citrix-Webclient with Firefox 84.0.2 (64-Bit) on Linux (ubuntu 20.04, manjaro) with multiple desktops - you can't select a specific desktop. Unfortunately, you can only select the entire screen. This is problematic, because the displayed screen is no longer readable by the meeting participants. Unfortunately I have to use other browsers like chromium, Edge ...

A small description as a picture PDF can be found here: https://drive.google.com/file/d/1Z0QCdd3jKSsky5YdFvtSN1-0FLDH_mY_/view?usp=sharing

I work for a company doing reports, due to the pandemic we need to project all the presentations remotely using services like Google Meet, but I use 2 screens, when I need to present a report together with the draft files, navigation, consoles, etc. I am obliged to project both screens instead of just one and people who have a notebook see the image too long, the same happens with mobile devices, I can't have my drafts on one screen and present on the second.

Not being able to present on a single screen is a problem.

Facing this same problem, the only workaround is to share a specific window - but that is not helpful in all cases. I am now falling back to Chromium only for calls where i have to present my screen.

in 2020/2021 this turns out to be a really useful feature enhancement!

+1 for implementing this feature!

Sharing window has bad effect: no dropdowns and such elements are visible to participants.

+1 for implementing this feature!

Even in
Firefox Developer Edition 88.0b1
is still unavailable.
I need to stick with Chrome for this.

Also a preview of the available screen/windows (like Chrome does) would be preferred instead of a flat textual list.

+1

+1

Attached image Your Entire Screen —

"Your Entire Screen" in Chromium has thumbnails of each screen so that the correct screen can be selected.

Is this feature planned to be implemented in Firefox? If so, is there an ETA?

Thank you

Linux user as a workaround I just use chrome or vlc in Screen Capture with

vlc \
    --no-video-deco \
    --no-embedded-video \
    --screen-fps=20 \
    --screen-top=32 \
    --screen-left=0 \
    --screen-width=1920 \
    --screen-height=1000 \
    screen://

nowadays is common for work environment to have an external monitor along with the laptop ones and it's a little bit frustrating to not be able to share a single monitor

(In reply to edoardo.zerbo from comment #28)

Linux user as a workaround I just use chrome or vlc in Screen Capture with

vlc \
    --no-video-deco \
    --no-embedded-video \
    --screen-fps=20 \
    --screen-top=32 \
    --screen-left=0 \
    --screen-width=1920 \
    --screen-height=1000 \
    screen://

nowadays is common for work environment to have an external monitor along with the laptop ones and it's a little bit frustrating to not be able to share a single monitor

Good tip.
But yes, I'm still waiting for official fix for this bug.

this workaround works for me

fplay -video_size 1920x1080 -framerate 25 -f x11grab -i :0.0+1366,0

share second screen (create window that captures the contents of second display)
laptop screen width: 1366 (second screen starts on the right of that, see xrandr or display settings)
second screen resolution: 1920x1080

put ffplay window in background, do not minimize

this also affects the latest version in fedora 34: firefox-89.0-1.fc34.x86_64
this bug is now over 4 years old and still not fixed. thats pretty ridiculous

Someone demonstrated Open Broadcaster Software, OBS Studio. OBS is not only a workaround but an improvement. Hopes this helps others who are experiencing challenges.

Thanks for the OBS workaround, but the workaround for me is at the moment to not use firefox at all, anymore, because of that. And instead use chromium.
I must have some way to share my screen in a simple way without hacking around or installing any further software.

Similar bug was fixed with chromium 83, yet still is present in firefox 90.0.2

(In reply to paskali2005 from comment #34)

Similar bug was fixed with chromium 83, yet still is present in firefox 90.0.2

https://bugs.chromium.org/p/chromium/issues/detail?id=437507

+1

Firefox 91.0.1 is affected.

All this time and this issue has not been fixed??

Are there problems stopping Mozilla from fixing this issue??

All this time and this issue has not been fixed??
Are there problems stopping Mozilla from fixing this issue??

It is a abandoned and unresolved issue:

Apparently it is a problem related to the detection of the second monitor due to the nvidia driver, in the nvidia panel only one monitor appears, but anyway xorg server is able to detect both, so I think the problem is in how gnome detects each monitor since in the screen position configurations there are two, but when applying the night mode it only applies to the first one.

The same problem with dual screen detection for brightnes or share screen for web browser is a same issue.

i dont have gnome, i use lightdm with xfce without any gnome app, so i dont think it is related to gnome

(In reply to oli from comment #41)

i dont have gnome, i use lightdm with xfce without any gnome app, so i dont think it is related to gnome

+1. The bug doesn't seem to be related to a distro. I use i3wm and the bug is present. When I have to share my screen I use Chromium which detects the screens properly.

(In reply to oli from comment #33)

Thanks for the OBS workaround, but the workaround for me is at the moment to not use firefox at all, anymore, because of that. And instead use chromium.
I must have some way to share my screen in a simple way without hacking around or installing any further software.

A simple way you can share a screen in multi-monitor setups is with Jami.

Keywords: parity-chrome, parity-edge

Hi, just tested this with Intel driver + Firefox v92 + XFCE v4.14 - with dual monitors you can only share both (unreadable) or single app.

For now I'm using Chrome for meetings, workarounds are nice but sadly I can't get my not tech coworkers to do that, so +1 to this bug :)

I periodically install Firefox just to see if this is fixed. I cannot believe this problem persists for years. I was dealing with vlc and fplay workarounds for a while but I do not want to do it anymore and I will not use Firefox until it is fixed. My machine is arch/dwm system with both intel and nvidia GPUs

I know that Mozilla has many other bugs to correct, but this issue is of basic necessity, it will be difficult for Firefox to win market share with this type of problems that last years. They should correct these problems before they start creating pretty theme systems.

Hi, I'm a Webex developer. This issue affects the user experience for the Webex web app on Linux since the maximum resolution we allow for screen sharing is 1080p and this effectively cuts the sharing resolution in half if the user is using 2 monitors (not to mention it might be a privacy issue if the user does not mean to share their content from another screen).

+1. firefox 94.0.1 is affected

Sharing one screen/window when remote work is very popular these days seems like killer feature to me and I quite can't understand why this bug has no priority. It was reported 4 years ago... Chrome can share single screen/window without a problem so it can be done.

How can we make this a priority? i've always use chrome for videocalls where i've to share screen because i've got dual monitor and don't want to share my whole desktop :S

(In reply to jorgenava.ro from comment #50)

How can we make this a priority? i've always use chrome for videocalls where i've to share screen because i've got dual monitor and don't want to share my whole desktop :S
Hi guess you should be satisfied soon:

Because I assume, that now that the new webrtc has been imported (https://bugzilla.mozilla.org/show_bug.cgi?id=1654112):
(In reply to Dan Minor [:dminor] from comment #13)

Unfortunately, taking these changes will have to wait until we do our next import of libwebrtc.

The mainstream fix (implementation) should be imported. But I am not competent enough to evaluate if the commit can be so cherry picked..
(In reply to Dan Minor [:dminor] from comment #12)

Upstream commit is: https://webrtc.googlesource.com/src.git/+/e952b78c283f5e54376561f7c7dd1460143c6112. We should be able to cherry pick it and apply to our local copy. I'll have a look.

We have the upstream changes we need. We also need to update our integration to use that code.

Basically do for the linux/X11 integration what we have done for the windows and mac backends.

Severity: normal → N/A
Type: defect → task
Rank: 25
Priority: P3 → P2

This was quite easy, yeah.

Assignee: nobody → apehrson
Status: REOPENED → ASSIGNED
Component: WebRTC → WebRTC: Audio/Video

(In reply to Andreas Pehrson [:pehrsons] from comment #53)

This was quite easy, yeah.

Thank you! With your action, you will achieve at least "Ohhhhhhh! Finally!"-effect than the odd- / Even-Print feature of december.

I thank you soooooooooo much! Will it be 97 or 98?

I'm sorry, i'm new on Linux and bugzilla and reporting bugs and stuff...does that mean that is going to be implemented soon? (also not a programmer :S sorry)

Here's a try run. You can test out the builds from that try run as they're public. Here's the one for linux x64.

I also removed a gn build flag (build system used for libwebrtc) so I'll have to re-generate some files (for our build system). So it could take a little while to get everything ready to land.

If you do try the build, please let me know how it works. I haven't had time to do extensive testing but I expect this to "just work".

(In reply to Andreas Pehrson [:pehrsons] from comment #56)

Here's a try run. You can test out the builds from that try run as they're public. Here's the one for linux x64.

I also removed a gn build flag (build system used for libwebrtc) so I'll have to re-generate some files (for our build system). So it could take a little while to get everything ready to land.

If you do try the build, please let me know how it works. I haven't had time to do extensive testing but I expect this to "just work".

Tested successfully on Ubuntu 18.04 LTS.

Test Configuration: 2 desktops with the same configuration for both of them (I do not know how to update my previous message, sorry)

Selection Screen 1 / Screen 2 both working (no complete regression testing like window sharing/full window, I assumed, there are already some automated tests)

Thanks! Yes, we have automated tests for single-monitor screen capture.

I can confirm that this work now as expected on FF 98.0a1 (2022-01-13). Launched FF in Wayland on Fedora 35 running Gnome Wayland session using dual displays (laptop and external monitor).

(In reply to situmam from comment #63)

I can confirm that this work now as expected on FF 98.0a1 (2022-01-13). Launched FF in Wayland on Fedora 35 running Gnome Wayland session using dual displays (laptop and external monitor).

That sounds like the pipewire backend, which is different from the x11 backend we're discussing here.

Pushed by pehrsons@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/eda98758937f
Generalize DesktopDeviceInfoImpl for screen capture like what has been done for window capture. r=ng
https://hg.mozilla.org/integration/autoland/rev/29299d85edb5
Remove traces of MULTI_MONITOR_SCREENSHARE. r=ng
https://hg.mozilla.org/integration/autoland/rev/620fe2a80516
Update generated build files. r=ng

(In reply to Andreas Pehrson [:pehrsons] from comment #56)

Here's a try run. You can test out the builds from that try run as they're public. Here's the one for linux x64.

I also removed a gn build flag (build system used for libwebrtc) so I'll have to re-generate some files (for our build system). So it could take a little while to get everything ready to land.

If you do try the build, please let me know how it works. I haven't had time to do extensive testing but I expect this to "just work".

I can confirm that this one on X11 is working fine

I am now able to share a single screen on google meet for work :D

https://hg.mozilla.org/mozilla-central/rev/eda98758937f
https://hg.mozilla.org/mozilla-central/rev/29299d85edb5
https://hg.mozilla.org/mozilla-central/rev/620fe2a80516

Status: ASSIGNED → RESOLVED
Closed: 4 years ago → 2 years ago
status-firefox98: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → 98 Branch
Flags: qe-verify+

Issue is verified on latest 98.0b4 build for ubuntu 16 and ubuntu 20.

Status: RESOLVED → VERIFIED
status-firefox98: fixed → verified
Flags: qe-verify+
Duplicate of this bug: 1695656
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: