Closed Bug 1663286 Opened 4 years ago Closed 3 years ago

Jitsi Meet Screen sharing doesn't work properly with Firefox 80-83 when presenter has a multi-monitor setup

Categories

(Core :: WebRTC: Audio/Video, defect, P3)

Product:
Core
Component:
WebRTC: Audio/Video
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX
Tracking Flags:
Tracking Status
firefox80 --- affected
firefox81 --- affected
firefox82 --- affected

People

(Reporter: ovari123, Unassigned)

References

Details

(Whiteboard: [jitsi-meet])

Attachments

(3 files, 1 obsolete file)

Screenshot from 2020-09-11 12-10-43.png
127.28 KB, image/png
Details
Presenter's aboutWebrtc.html file
46.16 KB, text/html
Details
aboutWebrtc.html from a non-multimonitor session on Linux X11
43.43 KB, application/octet-stream
Details

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

Steps to reproduce:

https://github.com/jitsi/jitsi-meet/issues/7642

Steps to reproduce:

  1. Open Firefox
  2. Open LibreOffice Impress presentation
  3. Menu Bar → Slide Show → Start from First Slide F5
  4. Alt+Tab to switch to Firefox, open a room on Jitsi Meet and share the screen Presenting: …
  5. When the presentation slides are changed, the other person with Firefox 80.0 (64-bit) only sees one slide, the slides do not change.

Server information:

  • Jitsi Meet version: Jitsi Meet
  • Operating System: 5th September 2020

Client information:

  • Screen share program: LibreOffice 7.0.1.2 Linux (64-bit) (deb)
  • Browser / app version: Firefox 80.0 (64-bit)
  • Operating System: Linux Mint 20 Cinnamon

Additional information:

  • All the participants in the Jitsi Meet Room were hidden, i.e. their video was turned off. Does this help to reproduce?
  • Is this a bug introduced with the updated Jitsi Meet program?
  • Is this a feature missing in Firefox 80 which the updated Jitsi Meet program requires? https://github.com/jitsi/jitsi-meet/issues/4758
  • Also didn't work when we shared a screen from a different program.
  • Worked when Chrome was used by the presenter and the view was using Firefox. However, the sound was not good for the Firefox viewers when their microphones were muted. When the viewer unmuted their microphones, then the sound from the presenter (on Chrome) was fine.

Thank you

Actual results:

Screen share does not show slide changes.

Expected results:

Screen share should work with Firefox.

Hi,

Thanks for the details. I was able to reproduce the bug on Windows 10 on the following versions:

	Release 80.0 (64-bit) and Nightly 782.0a1 (2020-09-10) (64-bit).

I believe that the severity is S4 or S3. I've chosen a component. If you consider that there's another component that's more proper for this case you may change it.

Best regards, Flor.

Status: UNCONFIRMED → NEW
status-firefox80: --- → affected
status-firefox81: --- → affected
status-firefox82: --- → affected
Component: Untriaged → WebRTC
Ever confirmed: true
Product: Firefox → Core
Version: 80 Branch → Trunk

Is this a regression? With the current situation where many places are locked down, events are happening online. Can this be fixed in say Firefox 80.1? Thank you

Flags: needinfo?(dminor)

This bug makes many online events not possible. Based on that should the severity be the highest?

  • Worked when Chrome was used by the presenter and the view was using Firefox. However, the sound was not good for the Firefox viewers when their microphones were muted. When the viewer unmuted their microphones, then the sound from the presenter (on Chrome) was fine.

The presenter's sound was only heard correctly by the viewers when the viewers' microphones were on. The sound should be heard correctly on the viewers Firefox browser when the viewer's microphones are turned off (which currently doesn't happen).

Thank you

Thank you Florencia Di Ciocco for confirming this bug. Can you please put [jitsi-meet] in the whiteboard? Thank you

Whiteboard: [jitsi-meet]

Thank you Florencia Di Ciocco for confirming this bug. Can you please put [jitsi-meet] in the whiteboard? Thank you

You're welcome :)

I tried this morning, and I'm unable to reproduce this problem using Firefox Nightly 82 and LibreOffice 7 on either Ubuntu 20.04 or Windows 10.

Flags: needinfo?(dminor)

(In reply to Óvári from comment #4)

  • Worked when Chrome was used by the presenter and the view was using Firefox. However, the sound was not good for the Firefox viewers when their microphones were muted. When the viewer unmuted their microphones, then the sound from the presenter (on Chrome) was fine.

The presenter's sound was only heard correctly by the viewers when the viewers' microphones were on. The sound should be heard correctly on the viewers Firefox browser when the viewer's microphones are turned off (which currently doesn't happen).

Thank you

Please file a separate bug for this.

Severity: -- → S3
Priority: -- → P3

I asked a colleague to test this as well. He had lots of problems on his first attempt from linux to OS X, the screenshare did not appear and there was no audio. On his second try, everything just worked. So perhaps there is something going intermittently wrong here. Maybe network conditions?

Jitsi screenshare was working fine for me at the time Bug 1642807 was filed. I attempted to do a mozregression, but like I said, the problem did not reproduce for me.

I'll try to run the mozregression now. I will be back in a few with the results.

It was a very weird and difficult Mozregression since there appeared several mistakes while doing it.
Sometimes I wasn't able to choose the freeofice program to share, it just wasn't on the list to pick.
Sometimes when I shared, the other side got a grey screen (I'll attach a screen capture).
Sometimes the viewer saw the first slide and got stuck there.
Sometimes the viewer saw many slides and then got stuck.

So I draw the line on works perfectly. Sadly the result wasn't the best:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2f2cb7c9bcced2ec48d8fba6a369af03d1b46f64&tochange=1600e73bdd901c5ac4b831c43e29f73d561aa816

Any suggestions?

Flags: needinfo?(dminor)

Thank you for running the mozregression. In that list, Bug 1652426 might be relevant. Byron, what do you think?

Flags: needinfo?(dminor) → needinfo?(docfaraday)

Possibly? It would be weird if so, since Chrome did not have this bug.

(In reply to Dan Minor [:dminor] from comment #8)

Please file a separate bug for this.

Done at https://bugzilla.mozilla.org/show_bug.cgi?id=1664571

Thank you

Bug 1663368 comment 14 Screen sharing doesn't work if the presenter and all the viewer are in audio-only mode. Screen sharing worked in Firefox in version 79 and before. Does simulcast stop broadcasting the screen share? Thank you

I tested just now, and screen sharing is working properly for me with the presenter and viewer in audio only mode, using a libreoffice slideshow in presentation mode on Linux.

This reproduced for me once, when I had two local computers on a call with a remote person. In that case, one of my local computers did not show the slides advancing, but the remote side saw things working as expected. At the time it reproduced, we were experiencing poor call quality including frozen video.

From my testing, it is not clear that there is a problem with screensharing itself or if this is a symptom of a more general problem with video quality on jitsi. It is also not obvious to me if this is a Firefox issue or a jitsi issue.

(In reply to Dan Minor [:dminor] from comment #17)

From my testing, it is not clear that there is a problem with screensharing itself or if this is a symptom of a more general problem with video quality on jitsi. It is also not obvious to me if this is a Firefox issue or a jitsi issue.

Screensharing with Jitsi works with Chrome but not with Firefox. Does that imply that this is a Firefox issue?

(In reply to Óvári from comment #18)

(In reply to Dan Minor [:dminor] from comment #17)

From my testing, it is not clear that there is a problem with screensharing itself or if this is a symptom of a more general problem with video quality on jitsi. It is also not obvious to me if this is a Firefox issue or a jitsi issue.

Screensharing with Jitsi works with Chrome but not with Firefox. Does that imply that this is a Firefox issue?

No, because it could be a Jitsi bug that only affects Firefox.

Tried again today with 6 people (including us) in a Jitsi Meet room. They couldn't see our screen share. We were using Linux Mint 20 Cinnamon 64-bit with Firefox 80.0.1 64-bit. The Jitsi Meet room in our Firefox browser showed the screen share.

A person using Firefox 32-bit on Windows 7 (32-bit) could only see the screen share once we stopped sharing the screen. It showed them the screen which was shared after we stopped screen sharing!?

There was a person on our local area network (Linux Mint 19.3 Cinnamon 64-bit with Firefox 80.0.1 64-bit) that also couldn't see the screen share. Perhaps Firefox no longer works when there a someone in the Jitsi Meet room on the local area network?

I've been regularly testing on Jitsi with two computers on the same local area network without problems, so I don't think that is the cause.

I was in a meeting this morning where this bug reproduced while using the Zoom web client in Firefox. They were presenting using LibreOffice Impress. I've reached out to the presenter to see if they can tell me the version of Firefox and the OS they were using. As far as I know, the Zoom web client only uses GetUserMedia and DataChannels, so if it is affected, that narrows down where the problem could be.

Óvári, have you only seen this problem using Impress, or does it show up when sharing other software, for instance, if you exported your slides to PDF and then presented those? Does it make a difference if you share the Window or the entire screen? Thank you for your patience while we sort this out!

Flags: needinfo?(ovari123)

I heard back, and the Zoom repro from this morning was Firefox 80 on Windows 7 using LibreOffice 7.0.1. They did say that they regularly have problems with LibreOffice while doing presentations, often keep a PDF version of the slides just in case, and so couldn't rule out a LibreOffice problem.

One other detail from the Zoom repro, they were using two screens, with Firefox on one screen and the presentation on the other. This isn't a configuration I've tested yet.

(In reply to Dan Minor [:dminor] from comment #21)

Zoom web client only uses GetUserMedia and DataChannels, so if it is affected, that narrows down where the problem could be.

Great!

Óvári, have you only seen this problem using Impress, or does it show up when sharing other software, for instance, if you exported your slides to PDF and then presented those?

The problem also happens with Xviewer.

Does it make a difference if you share the Window or the entire screen?

We only share a window as there we use 2 monitors.

Thank you for your patience while we sort this out!

Thank you for taking the time to find the cause and fix!

Flags: needinfo?(ovari123)

(In reply to Dan Minor [:dminor] from comment #22)

So couldn't rule out a LibreOffice problem.

The problem also happens with Xviewer. Does that rule out LibreOffice as a problem?

Firefox version up to 79 worked with sharing images with Xviewer or LibreOffice.

I reproduced this in Jitsi with Firefox 80.1 and 81.0 on Arch Linux. Tested with 81.0 today and it does not seem to depend on a participant having video active. My fellow tester also tried sharing their screen and after a while I saw like a freeze frame. Similar frozen obsolete frame was observed last week after a long delay.
I was sharing my Firefox window, to be exact.

Edit: also tested under Wayland and same problem.

(In reply to Óvári from comment #25)

(In reply to Dan Minor [:dminor] from comment #22)

So couldn't rule out a LibreOffice problem.

The problem also happens with Xviewer. Does that rule out LibreOffice as a problem?

Firefox version up to 79 worked with sharing images with Xviewer or LibreOffice.

I think it does rule out LibreOffice, thank you. It seemed unlikely that LibreOffice was the problem, but we have had reports in the past of certain applications not sharing properly while others worked.

(In reply to buovjaga from comment #26)

It does not seem to depend on a participant having video active.

When we used Jitsi Meet, all members had their videos turned off/inactive. We've only used screen share, no video.

My fellow tester also tried sharing their screen and after a while I saw like a freeze frame. Similar frozen obsolete frame was observed last week after a long delay.

When we stopped the screen share, that is when a person with Windows 7 (32-bit) and Firefox (32-bit) saw our screen share that was no longer shared. Perhaps we should have called it a "freeze frame" like juovjaga called it.

(In reply to Dan Minor [:dminor] from comment #27)

I think it does rule out LibreOffice, thank you. It seemed unlikely that LibreOffice was the problem, but we have had reports in the past of certain applications not sharing properly while others worked.

Please let us know if there is any other information you would like from us.

Can someone who can reproduce this attach a copy of about:webrtc to this bug with Nightly?

Flags: needinfo?(docfaraday) → needinfo?(ovari123)

(In reply to Byron Campen [:bwc] from comment #29)

Can someone who can reproduce this attach a copy of about:webrtc to this bug with Nightly?

For me, the page does not have any session stats or log data. I used an appimage of Nightly from https://github.com/srevinsaju/Firefox-AppImage/releases/tag/nightly

I tried debug mode, but after stopping it said "trace log can be found at: " without any location. AEC logging went to /tmp.

Plz help.

(In reply to Byron Campen [:bwc] from comment #29)

Can someone who can reproduce this attach a copy of about:webrtc to this bug with Nightly?

about:webrtc doesn't seem to work.

Firefox Nightly downloaded from https://www.mozilla.org/en-US/firefox/channel/desktop/
Linux Mint 20 Cinnamon 64-bit

Flags: needinfo?(ovari123)

Attached file is from the presenters computer. Does the file help?

  1. Opened https://meet.jit.si/PinkQuotasSpeculateWhereby
  2. Didn't allow camera
  3. Didn't allow microphone
  4. Created the Jitsi Meet room, presenter computer screen shared Xviewer 2.6.2 program of an image
  5. Once the presenter was in the Jitsi Room with screen sharing enabled, the view then joined the room using steps 1-3 above.
  • Jitsi Meet in Firefox on the presenter computer showed the screen share
  • Jitsi Meet in Firefox on the viewer computer did not show the screen share

Presenter computer
Firefox Nightly 83.0a1 (2020-09028) (64-bit)
Linux Mint 20 Cinnamon (64-bit)

Viewer computer
Firefox Nightly 83.0a1 (2020-09028) (64-bit)
Linux Mint 19.3 Cinnamon (64-bit)

Attachment #9178303 - Attachment is obsolete: true

Should the about:webrtc file from the viewer's computer be attached as that is Firefox instance that does not work?

  1. Not sure if the presenter doesn't sent the screen share data or the viewer isn't able to understand the screen share stream arriving.
  2. Not sure if not allowing video also stops the screen share from working. This shouldn't stop screen sharing as:
  • Firefox did work with Firefox 79 and below when blocking video and microphone;
  • this works when the presenter uses Jitsi Meet Electron App, based on Chromium, and the viewer is using Windows 7 (32-bit) with Firefox 81 (32-bit).

Thank you

When the presenter's computer only has one monitor, screen sharing shows on the viewer's computer.

When the presenter's computer has an external monitor, screen sharing does not show on the viewer's computer.

Seems to be a multi-monitor bug.

Can you reproduce?

Thank you

Flags: needinfo?(docfaraday)
Flags: needinfo?(dminor)
Summary: Jitsi Meet Screen sharing doesn't work properly with Firefox 80 → Jitsi Meet Screen sharing doesn't work properly with Firefox 80 when presenter has a multi-monitor setup
Summary: Jitsi Meet Screen sharing doesn't work properly with Firefox 80 when presenter has a multi-monitor setup → Jitsi Meet Screen sharing doesn't work properly with Firefox 80-83 when presenter has a multi-monitor setup

Thank you for confirming that is a problem with screensharing with multiple monitors. I don't have multiple monitors, which explains why I was not able to reproduce this problem.

Flags: needinfo?(dminor)

(In reply to Dan Minor [:dminor] from comment #35)

Thank you for confirming that is a problem with screensharing with multiple monitors. I don't have multiple monitors, which explains why I was not able to reproduce this problem.

It's not limited to multiple monitors, though. I have reproduced this with a desktop and a laptop without any multiple monitors involved.

(In reply to Óvári from comment #31)

Created attachment 9178303 [details]
Firefox Nightly 83.0a1 (2020-09028) (64-bit)

(In reply to Byron Campen [:bwc] from comment #29)

Can someone who can reproduce this attach a copy of about:webrtc to this bug with Nightly?

about:webrtc doesn't seem to work.

Firefox Nightly downloaded from https://www.mozilla.org/en-US/firefox/channel/desktop/
Linux Mint 20 Cinnamon 64-bit

Try loading about:webrtc during the call.

Flags: needinfo?(docfaraday)
Component: WebRTC → WebRTC: Audio/Video
See Also: → 1668028

(In reply to Byron Campen [:bwc] from comment #37)

Try loading about:webrtc during the call.

Attached at bug 1663286 comment 32.

Finally managed to figure out that I need to refresh the page while in a Jitsi session. I tried to share my Firefox Window in this session.

The latest Jitsi Meet release
2.0.5142 (20-10-14)
jitsi-meet 1.0.4466

worked around the problem:
Disable RTX on Firefox. Disable RTX on FF as we are seeing video freezes on FF80 and later - https://bugzilla.mozilla.org/show_bug.cgi?id=1668028
https://github.com/jitsi/jitsi-meet-release-notes/blob/master/CHANGELOG-WEB.md

Screensharing in Firefox works for me again with our Jitsi Meet after that update.

Last month, Jitsi re-enabled RTX for Firefox >83: https://github.com/jitsi/lib-jitsi-meet/commit/5891fa5b79f567a9c76d84ab566573abe2581634
However, yesterday on meet.jit.si with two parties using Firefox 85, screen sharing did not work. The Jitsi Meet version was 4685.1338 at the time.

(In reply to buovjaga from comment #41)

Last month, Jitsi re-enabled RTX for Firefox >83: https://github.com/jitsi/lib-jitsi-meet/commit/5891fa5b79f567a9c76d84ab566573abe2581634
However, yesterday on meet.jit.si with two parties using Firefox 85, screen sharing did not work. The Jitsi Meet version was 4685.1338 at the time.

This was with me sharing screen on Linux while the other party was using Windows. Now I tested with another person while we both used Linux and screensharing worked ok.

Screen sharing in Jitsi with multiple monitors on Fedora 34 GNOME Wayland Linux works fine for me in 88.0.1 (64-bit).

(In reply to Jan Vlug from comment #43)

Screen sharing in Jitsi with multiple monitors on Fedora 34 GNOME Wayland Linux works fine for me in 88.0.1 (64-bit).

Thanks for your reply. Can you confirm that you had someone who could see your screen share and was using an iPad?

We have shared a screen and everything on our side looked fine, yet people who are using the Jitsi Meet app for iPad could not see the screen share. It is understood that they are using the app from:
https://apps.apple.com/us/app/jitsi-meet/id1165103905

We are sharing with Linux Mint 20.1 Cinnamon which, as we understand, does not have Wayland.

Thank you

(In reply to Óvári from comment #44)

Can you confirm that you had someone who could see your screen share and was using an iPad?

No, I cannot confirm that.

Closing due to https://github.com/jitsi/jitsi-meet/issues/7369#event-4948152557

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX

Hi there!

I'm facing the same sort of problem here. Using either Firefox 88.0.1 (64-bit) or 90.0.4430.212 (Developer Build), both running on Debian bookworm/sid, I can't share camera, window or whole screen here. The funny thing is that it worked well last Tuesday and the day after it was broken.

I use to have two monitors here, but it doen't work any more even when I turn off one of them. On the other devices here (mobiles and on Safari at a MacBook it runs pretty well).

Any help?

Best regards, Alexandre

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: