1536777 - Screen sharing only working for top-left quarter of screen (OSX dual-monitor)

Status: RESOLVED WORKSFORME

(Core :: WebRTC, defect, P2)

Description

[Gavin Llewellyn]

Attachment: Firefox screen share corruption.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:66.0) Gecko/20100101 Firefox/66.0

Steps to reproduce:

On a MacBook Pro (Retina, 15-inch, Mid 2015), with a dual-screen setup:

• Built-in Retina display: 15.4-inch (2880 x 1800)
• External DisplayPort monitor: 25-inch (2560 x 1440)

1. Open any WebRTC-based site that can share the screen (e.g. https://www.webrtc-experiment.com/Pluginfree-Screen-Sharing/).
2. Select "Screen 1" (the Retina display).
3. Move some windows around.

Actual results:

In the web page's local view of the captured screen, the initial captured image looks perfect. However, once windows start getting moved, only the top-left quarter of the screen is updated reliably; some rectangular portions in the middle are updated, but the bottom and right of the screen never change.

Expected results:

The full captured image should be updated whenever the screen changes.

I found some similar issues from two years ago (bug #1395289, bug #1392565), but they were believed to be fixed. Perhaps this is due to a mixture of Retina and non-Retina screens; I was not able to reproduce the issue with my external monitor unplugged.

Comment 1

[Michael Froman [:mjf]]

Nils, any thoughts here?

Comment 2

[Nils Ohlmeier [:drno]]

Dan, is it possible that our last webrtc.org update regressed something here again?

Comment 3

[Dan Minor [:dminor]]

I'm unable to reproduce this bug using my mid-2015 Retina MacBook Pro and an external monitor connected through HDMI. Screensharing on both the main display and the secondary display were working in this configuration.

That said, my secondary display is actually my sony tv running at 1080p, so maybe there is something special with DisplayPort or the monitor resolution being used that causes this to reproduce.

I'm not sure offhand if this is a regression or something that has never worked properly.

Comment 4

[Daniel Bodea [:danibodea]]

I have also attempted to reproduce this issue on MacBook Pro 2017 with OS 10.13.6 and could not reproduce.
However, I also attempted its reproduction on another MacBook Pro 2017 with OS 10.14.6 and I successfully reproduced it using an HD monitor and linked through an HDMI cable and a TypeC->HDMI adaptor.

I have attempted to find its regressor and I found out that it reproduces as far back as Nightly 66.
Older builds cannot be tested because the WebRTC Sharing app is not compatible with firefox65 or older.

@Gavin: Can you provide us with other WebRTC applications that reproduce your issue?
@assignee/dev: considering the information above, do you still need me to try to find a regression if it's older than firefox 66?

Thank you for your contribution!

Comment 5

[Dan Minor [:dminor]]

Thank you for finding a system configuration that reproduces this. Using https://mozilla.github.io/webrtc-landing/gum_test.html might allow you to test this on on older versions of Firefox. If it works on Firefox 64 and is broken on Firefox 65, that would pinpoint the last webrtc.org update as the regressor. I don't think it's worth spending time on versions of Firefox older than 64. Thank you for looking into this!

Comment 6

[Gavin Llewellyn]

I've just re-tested using Firefox 72.0.1, and was able to reproduce using https://mozilla.github.io/webrtc-landing/gum_test.html as well as the example in the original description. I am also using macOS 10.14.6 (Mojave).

Comment 7

[Daniel Bodea [:danibodea]]

I have also tried reproducing the issue on older versions, but the second WebRTC screen share test page is still unusable.
Removing the "regressionwindow-wanted" tag. If there is another screen sharing web app that works on older versions, I am still willing to try. It appears to me that older versions are incompatible with this kind of apps.

I want to say that id definitely is NOT a recent regression. Not sure whether it is a regression at all.

Comment 8

[Christian Walther]

I am also seeing this with Firefox 75.0 on macOS 10.14.6. One symptom that I haven’t seen mentioned yet is that the sub-rectangle of the second screen that is correctly refreshed seems to depend on the position of the Firefox window on the main screen – it moves when the window is moved (in a way I haven’t been able to make sense of yet). Also, when I switch applications, sometimes different parts of the shared screen are updated (once).

My setup: MacBook Pro with internal 2880 x 1800 retina display (this is where the Firefox window is), external HDMI 1280 x 720 display arranged to the right of the main screen (this is the screen that is being shared).

Possible duplicate: bug 1599441

Comment 9

[mathias]

This is still happening on Firefox 89 on macOS 11.2.3.

It only updates a part of the screen, the cursor however continues to be updated across the whole screen.
If I move Firefox to the screen being shared it works as expected.

My display is connected via a display port and arranged on top of each other.

This is quite annoying as I need to switch to another browser to share my monitor on any video conference - if I want to keep the call on another monitor.

Built-in Retina Display - 13.3-inch (2560 × 1600)
LG HDR 4K Display - 27-inch (3840 × 2160)

Comment 12

[William Lachance (:wlach)]

I can reproduce this on Firefox 100.0b2 (Mac OS X 12.2.1) with Google Meet (Hangouts) and the same retina laptop / non retina display people have been talking about. Pretty frustrating bug.

I'm not sure if this is so important, but can someone make this bug block hangouts (bug 1431543). Apparently I don't have permissions to do this.

Comment 13

[William Lachance (:wlach)]

I poked around with this a bit more after spelunking through some Chromium bugs (e.g. https://bugs.chromium.org/p/chromium/issues/detail?id=1056311).

As best as I can tell, it seems like the bug is only exhibited when sharing a window from a different screen. So if I share screen 2 (my non-retina) from a browser tab on screen 2, it share fine. Same with screen 1. It's only if I try to share screen 2 from screen 1, or screen 1 from screen 2 that I run into problems.

Note that despite the fact that that there are a bunch of open bugs with Chromium, it does not reproduce on the version of Chrome that I'm using (100) best as I can tell

Comment 14

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

I can confirm comment 13.

Comment 15

[William Lachance (:wlach)]

(In reply to William Lachance (:wlach) from comment #13)

As best as I can tell, it seems like the bug is only exhibited when sharing a window from a different screen. So if I share screen 2 (my non-retina) from a browser tab on screen 2, it share fine. Same with screen 1. It's only if I try to share screen 2 from screen 1, or screen 1 from screen 2 that I run into problems.

Just a note after trying this for a few days: this seems to work initially but then the problem recurs, even if I keep the screens shared on the same monitor. The only workaround I've found that works consistently is unplugging my monitor before giving a presentation.

Comment 16

[William Lachance (:wlach)]

I haven't been able to reproduce this since upgrading to MacOS Ventura (not entirely sure if that's due to a fix in Firefox or Ventura, could probably use mozregression with an older build to verify). I'll try to take a look when I have a moment.

Comment 17

[William Lachance (:wlach)]

(In reply to William Lachance (:wlach) from comment #16)

I haven't been able to reproduce this since upgrading to MacOS Ventura (not entirely sure if that's due to a fix in Firefox or Ventura, could probably use mozregression with an older build to verify). I'll try to take a look when I have a moment.

Verified that older versions of Firefox work fine here too (tried with the March 1st 2022 nightly), so it looks like it's something that either changed in MacOS Ventura or (probably less likely) hangouts since I last commented on this bug.

Comment 18

[Jim Mathies [:jimm]]

Still running into this wlach?

Comment 19

[Christian Walther]

I can no longer reproduce this with Firefox 115.1.0esr, while I still can with 75.0, which probably means it’s fixed. Still on macOS 10.14.6, but with a different dual-screen setup.

Comment 20

[William Lachance (:wlach)]

(In reply to Jim Mathies [:jimm] from comment #18)

Still running into this wlach?

Yup, this has been working for me since I last commented. Please resolve.