2000906 - Sharing the entire screen on Teams fails

Status: ASSIGNED

(Web Compatibility :: Site Reports, defect, P1)

Description

[Simona Badau, Desktop QA]

Attachment: Screenshot with the issue

Found in

• Firefox 146.0b4

Affected versions

• Nightly 147.0a1
• Firefox 146.0b4
• Firefox 145.0.1

Tested platforms

• Affected platforms: macOS 15, macOS 13

Preconditions

• Engage in a call between Windows 10 and macOS 15 on Teams
• On macOS - ensure the following preferences are set:
  privacy.webrtc.allowSilencingNotifications to true
  privacy.webrtc.legacyGlobalIndicator to false

Steps to reproduce

1. On macOS, click on Share -> choose "Screen, window or tab" -> in Share permission dialog select "Use operating system" and click Allow -> choose "Share Entire Screen"
2. Observe the quality/output of the Shared screen.

Expected result

• The entire screen should be properly captured and displayed to the remote user.

Actual result

• The entire screen is not shared - despite seeing a correct local preview in the macOS system share UI, the remote user receives an empty screen - please see the screenshot.

Regression range

• This appears to be a regression - the issue does not reproduce in Firefox 140.5.0esr. I will look for a regression window as soon as possible.

Additional notes

• There are no issues when selecting "Share This Window" instead of "Share Entire Screen".

Comment 1

[Andreas Pehrson [:pehrsons]]

mozregression says https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=4bbcdd88d4e30919e4ea4e1c4d7d40d1eb5c985b&tochange=7853fc75c89a35522084a5be4aae236e9a07d28e

Noting there is nothing platform specific there; marking all desktop platforms.

Could still be a site issue. Maybe the captured resolution changed and it burns some bitrate limit downstream? This needs further diagnosis.

Comment 2

[Andreas Pehrson [:pehrsons]]

Hi, was this test case covered in the test plan? I'm curious as to why we didn't catch it earlier. Thanks

Comment 3

[Andreas Pehrson [:pehrsons]]

Interesting difference in the number of capture tracks. The links are to a second's worth of incoming captured frames from the parent process to the content process. Before, After.

In general I have had trouble reproducing with logging enabled prior to the regression. I have seen two differences so far. One is that the number of tracks from the capturers in the parent process are two (1 camera, 1 screen) prior to the regression, and 12 (8 camera, 4 screen) after. After the regression I also see more video send streams signaled than before, but we're still only sending one for screen capture and one for camera.

Smells like a site issue.

Comment 4

[Andreas Pehrson [:pehrsons]]

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

Interesting difference in the number of capture tracks. The links are to a second's worth of incoming captured frames from the parent process to the content process. Before, After.

This appears to be because I was testing in a local build that has the bug 1771789 patches, and they do a bunch of cloning of capture tracks.

I had some luck setting the media.navigator.video.resize_mode.enabled pref to false. They are doing some feature detection there and setting resizeMode: "none" together with width and height constraints, which seems odd.

But generally things aren't working great even with that pref flip. Audio and video (camera) streams don't always start as expected. Screen captures tend to freeze for the receiver even though we keep sending, just like the symptom here but a bit delayed. Once the screen capture has gone, it seems impossible to recover by turning it off and on again.

Comment 5

[Andreas Pehrson [:pehrsons]]

The resizeMode: "none" together with width, height and frameRate constraints makes us ignore the width, height and frameRate ones, which seems to be the culprit. I assume we exceed some threshold in the SFU which then cuts us out. Chrome appears to ignore resizeMode: "none" for getDisplayMedia which explains a bit.

We could do an intervention to set media.navigator.video.resize_mode.enabled to false for teams.microsoft.com (and teams.live.com ?), but --

We do have a slight bug 1286945 regression for when the media.navigator.video.resize_mode.enabled pref is false where we used to default to 30fps capture and allow framerate decimation but now do 60fps always. That could have an impact on bitrate for instance, because we did see some cases while testing that led to a frozen screen capture remotely, with the pref flipped in Nightly.

Comment 6

[Sky Schubert [:skyschub]]

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

We could do an intervention to set media.navigator.video.resize_mode.enabled to false for teams.microsoft.com (and teams.live.com ?)

Interventions to set prefs are not a thing because the pref system doesn't operate per-site. What we could do, with some effort, is to re-work that pref to have a origin allowlist via nsIPrincipal:: isURIInPrefList, but that's not trivial.

From comment 4, it sounds like even if we would flip that pref, it'd still be somewhat broken, and we don't understand why. We either need more diagnosis from the WebRTC team, or we need to get in touch with Microsoft.

Comment 7

[Andreas Pehrson [:pehrsons]]

(In reply to Dennis Schubert [:denschub] from comment #6)

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

We could do an intervention to set media.navigator.video.resize_mode.enabled to false for teams.microsoft.com (and teams.live.com ?)

Interventions to set prefs are not a thing because the pref system doesn't operate per-site. What we could do, with some effort, is to re-work that pref to have a origin allowlist via nsIPrincipal:: isURIInPrefList, but that's not trivial.

Right, ok. But could an intervention intercept getDisplayMedia and remove the resizeMode constraint if present?

From comment 4, it sounds like even if we would flip that pref, it'd still be somewhat broken, and we don't understand why. We either need more diagnosis from the WebRTC team, or we need to get in touch with Microsoft.

That's a bug on our end. I'll fix that.

Comment 8

[Thomas Wisniewski [:twisniewski]]

Right, ok. But could an intervention intercept getDisplayMedia and remove the resizeMode constraint if present?

Yes, that ought to be possible. If you'd like some help writing up a patch to test with, just let me know and we can strike up a chat on Slack/Matrix.

Comment 9

[Simona Badau, Desktop QA]

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

Hi, was this test case covered in the test plan? I'm curious as to why we didn't catch it earlier. Thanks

Yes, it is covered.
I noticed that if screen sharing was previously started (either entire screen or a specific window), that captured image is reused and shown again when sharing. Only on new profiles the sharing view appears empty.

Comment 10

[Andreas Pehrson [:pehrsons]]

(In reply to Simona Badau, Desktop QA from comment #9)

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

Hi, was this test case covered in the test plan? I'm curious as to why we didn't catch it earlier. Thanks

Yes, it is covered.
I noticed that if screen sharing was previously started (either entire screen or a specific window), that captured image is reused and shown again when sharing. Only on new profiles the sharing view appears empty.

Yes, this may be the receiver or Teams' SFU (a middlebox) remembering the last image. I think most likely it's the receiver, and the SFU has stopped forwarding video -- because we're still sending.

Comment 11

[Andreas Pehrson [:pehrsons]]

Attachment: Bug 2000906 - On Microsoft Teams, drop resizeMode: "none" in gDM. r?jib!,twisniewski!

Drop the resizeMode constraint from gDM when used counter-productively with any
other constraint that causes downscaling or framerate decimation.

Also drop it from applyConstraints if not already present since track creation,
i.e. when previously dropped per the condition mentioned above.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/44be98e9e699
https://hg.mozilla.org/integration/autoland/rev/8eab5246eea5
On Microsoft Teams, drop resizeMode: "none" in gDM. r=jib,twisniewski,webcompat-reviewers

Comment 13

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/8eab5246eea5

Comment 14

[Andreas Pehrson [:pehrsons]]

I gave screensharing a spin in Teams on all desktop platforms (basic case of a 1:1 meeting) and it seems fine with the intervention in place.

Comment 15

[Dimitrios Apostolou]

I and several colleagues of mine on Linux were struggling for some time with what seems to be the same issue: screenshare on Teams meetings was blank for the people receiving the screenshare. Unfortunately several of them migrated away from Firefox because of work urgency.

Trying today's Firefox 147a Nightly build and screenshare works again!
For everybody's information then I am assuming it's the same bug despite the bug description saying "when done from macOS".

Is there a workaround for users that don't want to install Nightly or wait until it becomes mainline?
Thank you!

Comment 16

[Randell Jesup [:jesup] (needinfo me)]

Tom - can the intervention be uplifted?

Comment 17

[Thomas Wisniewski [:twisniewski]]

Yes, though I'm waiting on Andreas' opinion, since he asked for it to ship normally on the trains (but that was before we received the feedback in comment 15).

Comment 18

[Andreas Pehrson [:pehrsons]]

I think the intervention is defensive enough to uplift.

Comment 19

[Thomas Wisniewski [:twisniewski]]

Attachment: Bug 2000906 - On Microsoft Teams, drop resizeMode: none in gDM

Comment 20

[Andreas Pehrson [:pehrsons]]

To summarize our findings and what the intervention does:

• Firefox 145 shipped the resizeMode constraint and this broke screensharing in Teams.
• What I observed Teams doing on screencapture (from the top of my head):
  • getDisplayMedia({resizeMode: "none", width: {max: 1920}, height: {max: 1080}, frameRate: {max: 15}}), which works in limiting the resolution even in presence of resizeMode: "none" (which says to use the display surface's native resolution and framerate). We don't decimate the framerate here, which may be a bug.
  • The gDM (getDisplayMedia) track is cloned a bunch of times.
  • Those tracks originating from gDM have applyConstraints called on them a number of times collectively, with slightly different width/height (off by one at most). Essentially Teams does (for my MBP's monitor at 3024x1964) applyConstraints({resizeMode: "none", width: 1663, height: 1080, frameRate: 15}), which due to the presence of resizeMode: "none" won't downscale (per spec it's hit or miss what has shortest fitness distance, depending on resolution, though we may always go for the native values in this case).
  • I observed that Teams' middlebox/SFU drops the screencapture video if we send it 3024x1964@60 (though in practice we encode at a lower rate). Same for 1663x1080@60 (resizeMode disabled by pref; that we do 60 here is bug 2001764).
• The intervention intercepts the call to getDisplayMedia and if resizeMode: "none" is present in constraints with some value for either of width, height or frameRate, we drop resizeMode such that Firefox will default to resizeMode: "crop-and-scale".
  • The intervention further intercepts MediaStreamTrack.applyConstraints and if the track does not have a resizeMode constraint already (heuristic for it being a gDM track), we apply the same logic as in the intercepted gDM method.
• If Teams were to change to no resizeMode constraint or resizeMode: "crop-and-scale" for gDM+applyConstraints-on-gDM-tracks, the intervention will do nothing and we can eventually disable it.

Comment 21

[Dimitrios Apostolou]

Thank you for the detailed description, it breaks the issue down very well.

If Teams were to change to no resizeMode constraint or resizeMode: "crop-and-scale" for gDM+applyConstraints-on-gDM-tracks, the intervention will do nothing and we can eventually disable it.

It sounds to me that this is a bug in Teams triggering undefined behavior because of the contradicting parameters it passes, and that the fastest-to-deploy fix would be in Teams itself.

Do you have a channel for contacting the Teams team directly? I've left "feedback" from inside the Teams application several times in the last month, but I don't think I'll ever get a response.

Comment 22

[Dimitrios Apostolou]

Thank you for the detailed description, it breaks the issue down very well.

If Teams were to change to no resizeMode constraint or resizeMode: "crop-and-scale" for gDM+applyConstraints-on-gDM-tracks, the intervention will do nothing and we can eventually disable it.

It sounds to me that this is a bug in Teams triggering undefined behavior because of the contradicting parameters it passes, and that the fastest-to-deploy fix would be in Teams itself.

Do you have a channel for contacting the Teams team directly? I've left "feedback" from inside the Teams application several times in the last month, but I don't think I'll ever get a response.

Comment 23

[Dimitrios Apostolou]

Oh great, a bugzilla bug now. After I submitted my comment it presented me with conflicting changes from others, and I selected something like "post only my new comment", and apparently it got double-posted...

Comment 24

[Andreas Pehrson [:pehrsons]]

(In reply to Dimitrios Apostolou from comment #21)

Do you have a channel for contacting the Teams team directly? I've left "feedback" from inside the Teams application several times in the last month, but I don't think I'll ever get a response.

We'll get the intervention into 146, and we're reaching out to Teams about this as well.

I marked those comments as duplicates so they get folded away.

Comment 25

[Thomas Wisniewski [:twisniewski]]

Comment on attachment 9530864 [details]
Bug 2000906 - On Microsoft Teams, drop resizeMode: none in gDM

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency: Sharing one's entire screen will not work in Microsoft Teams.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This intervention is defensively coded, users have confirmed it does its job, and it only affects Teams and the webcompat addon.
• String changes made/needed: no
• Is Android affected?: No

Comment 26

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 27

[Thomas Wisniewski [:twisniewski]]

We just began rolling out an addon update to the just-released Firefox 146 to get this intervention there. Hopefully all 146 users will automatically get it over the next day or two, but if anyone is really impatient and wants to speed that up, you can open the Browser Console and run an update-check manually:

1. open the Firefox DevTools, and the open their settings via the three-dot menu.
2. in the settings, enable the checkbox Enable browser chrome and add-on debugging toolboxes.
3. open the Firefox Browser Console (on Linux and Windows, press Ctrl+Shift+J to open it; on macOS, it's Cmd+Shift+J; it's also in the Tools menu->Browser Tools)
4. run this command in the Browser Console: ChromeUtils.importESModule("resource://gre/modules/AddonManager.sys.mjs", { global: "shared" }).AddonManagerPrivate.backgroundUpdateCheck(); (it should say "pending")
5. close the Browser Console and wait a few seconds
6. in about:support you should see that "Web Compatibility Interventions" is now version 148.0.20251209.16142 (you can refresh about:support every few seconds until it does).
7. refresh any MS Teams tab for the intervention to kick in.

Comment 28

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/70c4c5111f21
https://hg.mozilla.org/releases/mozilla-release/rev/8bf9f3cc21e5

Comment 29

[Simona Badau, Desktop QA]

Verified as fixed using Firefox 146.0.1 - in a 3 persons call, screen sharing the entire screen or just a window is visible when done from Ubuntu 24.04, macOS 15 and Windows 11 x64.

But we noticed that there is an issue on the latest Nightly 148.0a1 and on Firefox 147.0b5 with the speakers. In a call of 3 persons, only one of us was able to hear all the other participants - the other two could not hear.

@Andreas - could this be related with the fix/intervention that was done here?

Comment 30

[Andreas Pehrson [:pehrsons]]

An audio issue seems like unlikely fallout. I have seen similar issues for both audio (mic) and video (camera) when testing during development, but I didn't find it to be consistent. That said, it seemed to me like muting/unmuting on the sending side would sometimes help. If you find an STR that seems fairly consistent, could you file another bug for this? Thanks.

Comment 31

[Simona Badau, Desktop QA]

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

An audio issue seems like unlikely fallout. I have seen similar issues for both audio (mic) and video (camera) when testing during development, but I didn't find it to be consistent. That said, it seemed to me like muting/unmuting on the sending side would sometimes help. If you find an STR that seems fairly consistent, could you file another bug for this? Thanks.

I logged Bug 2006940. Thank you!

Comment 32

[Simona Badau, Desktop QA]

Verified as fixed also using Firefox 147.0b5 - screen sharing the entire screen or just a window is properly done between Ubuntu 22.04, macOS 15 and Windows 11 x64.

Comment 33

[Simona Badau, Desktop QA]

I also checked using the latest Nightly 148.0a1, and screen sharing works there as well.

Comment 34

[Donal Meehan [:dmeehan]]

See comment 33

Comment 35

[Dimitrios Apostolou]

Works for me too, on both 146 and nightly. Thank you for the fix.

Comment 36

[Dimitrios Apostolou]

Did this regress somehow?
I had a Teams call yesterday (Firefox 148 on Linux) and a few people on the call reported my screen sharing was blank.

Comment 37

[Andreas Pehrson [:pehrsons]]

(In reply to Dimitrios Apostolou from comment #36)

Did this regress somehow?
I had a Teams call yesterday (Firefox 148 on Linux) and a few people on the call reported my screen sharing was blank.

I just gave it a spin on Nightly macOS and it seemed to work fine. If it happens again, please grab a logging profile for a few seconds (about:logging -> webrtc preset) so we can see if it's a problem with capture or sending. Upload the resulting profile including hidden threads (or at least all threads for the parent process and the process hosting Teams) and share it here, please.

Comment 38

[jhudson]

It's broken for me. Same fault location:

const proto = Object.getPrototypeOf(navigator).wrappedJSObject;
const { registerProtocolHandler } = proto;

Can confirm Object.getPrototypeOf(navigator).wrappedJSObject returns undefined at global scope.

Web Compatibility Interventions extension 148.7.0

Comment 39

[jhudson]

Is there a way to turn this specific compat off? It cannot function.

Comment 40

[Thomas Wisniewski [:twisniewski]]

The problem should go away when you upgrade to Firefox 149, where the current version of the addon is 149.10.0.

But if you're somehow "stuck", you can also add this preference in about:config and set it to true: extensions.webcompat.disabled_interventions.2000906

That will disable it until you remove the pref (you should see that Teams is disabled in about:compat and you can't re-enable it while the perf is true).

Comment 41

[jhudson]

Can confirm; manual upgrade fixed it for me. Not sure why upgrade didn't notice until I ordered it to check.

Comment 42

[Dimitrios Apostolou]

Firefox 149 on Linux here and some people can't see my screen sharing.
Weirdly enough, I verified that at least another with similar setup (Firefox 150 on Linux) couldn't see my screen. And I couldn't see his.
NB: this does not happen in a one-to-one video call. Only in group meetings.

But if you're somehow "stuck", you can also add this preference in about:config and set it to true: extensions.webcompat.disabled_interventions.2000906

That will disable it until you remove the pref (you should see that Teams is disabled in about:compat and you can't re-enable it while the perf is true).

This doesn't do anything for me, and about:compat is empty.

Comment 43

[Thomas Wisniewski [:twisniewski]]

If about:compat is empty then our work-arounds for site issues aren't working at all, so the pref won't do anything. Does about:compat show any text at all? If not, is "Web Compatibility Interventions" listed in about:support? If so, do you maybe have this pref set to false? extensions.webcompat.enable_interventions

Comment 44

[Dimitrios Apostolou]

The about:compat page is a completely empty white page.
The enable_interventions pref in about:config is true.
about:support shows

Web Compatibility Interventions	extension	151.3.20260409.134825	true	app-system-addons	[e-mail]

Comment 45

[Dimitrios Apostolou]

I have a webrtc log taken with about:logging webrtc profile, size is about 3MB uncompressed. I disabled all other audio/video sharing and:

1. enabled logging, 2. shared my screen, 3. wait, 4. unshare the screen, 5. disabled logging.

I don't see any "error" messages in the log. I'm not sure if I should upload it here, does such a log contain private information?

Comment 46

[Thomas Wisniewski [:twisniewski]]

The about:compat page is a completely empty white page.

That certainly shouldn't be the case. If you're willing, could you check the browser console in the tools/browser tools menu for any information regarding the webcompat addon? It sounds like something went wrong. If not, have you restarted your browser anytime recently? That may bring about:compat back as well.

Comment 47

[Dimitrios Apostolou]

Only one message is logged in the browser console while loading about:compat:

Error: Failed to load resource://webcompat/AboutCompat.sys.mjs

P.S. this is now Firefox 150.0 from the OpenSUSE Tumbleweed repos. It's not the official mozilla build.

Comment 48

[Thomas Wisniewski [:twisniewski]]

Hmm. Then it sounds like something is broken with the webcompat addon on that build. If that file is unable to load, then about:compat certainly won't work.

Comment 49

[Dimitrios Apostolou]

New tests just completed:

• Screen sharing from OpenSUSE Tumbleweed Firefox 150 with about:compat failing to load.

  • It is visible to others on Teams app on Windows, invisible to others on Firefox/Chromium on Linux

• Screen sharing from Mozilla Firefox 152 Nightly on Linux with about:compat loading properly

  • Same as above, screenshare invisible to non-windows users!

• Screen sharing from Chromium on Linux

  • Screen sharing is visible to everyone.

P.S. side-quest: can you think of a reason about:compat fails to load on the OpenSUSE Firefox? I can file a distro bug if we figure something out.

Comment 50

[Dimitrios Apostolou]

It's actually trivial for me to reproduce:

• Join the Teams meeting from Firefox on Linux (1).
• Open another browser (2) of your choice and login to Teams using the same account. Join the same meeting.
• Screen-share from (1).
• Check if it's visible from (2).

NB. it must be a Teams meeting. Not a call (these work fine).

Can somebody try to reproduce?

Comment 51

[Andreas Pehrson [:pehrsons]]

(In reply to Dimitrios Apostolou from comment #50)

It's actually trivial for me to reproduce:

• Join the Teams meeting from Firefox on Linux (1).
• Open another browser (2) of your choice and login to Teams using the same account. Join the same meeting.
• Screen-share from (1).
• Check if it's visible from (2).

NB. it must be a Teams meeting. Not a call (these work fine).

Can somebody try to reproduce?

This sounds like the issue the webcompat addon fixes, so I'd say the webcompat addon not working is your root cause. Apart from Teams doing something weird in the first place.

What if you manually limit the captured screen resolution by sharing a small window, or making your screen resolution really small (e.g. 640x480)? Or if you disable resizeMode support by, on about:config, setting the pref media.navigator.video.resize_mode.enabled to false? Note the latter will not scale as it may break other sites and even Teams' own camera capture, depending on camera capabilities. So please re-enable the resize_mode.enabled once you're done testing.

Comment 52

[Dimitrios Apostolou]

Hi Andreas, check my message above, I actually tested with the official Nightly build, with about:compat working fine and the issue persisted:

• Screen sharing from Mozilla Firefox 152 Nightly on Linux with about:compat loading properly

  • Same as above, screenshare invisible to non-windows users!

Will also try one of the scenarios you described when I get some time.

Comment 53

[Dimitrios Apostolou]

What if you manually limit the captured screen resolution by sharing a small window, or making your screen resolution really small (e.g. 640x480)?

This was easy to test, just tried sharing a small window from the "bad" firefox (the one with broken about:compat). It worked!

Comment 54

[Dimitrios Apostolou]

I have a suspicion. about:compat on my Mozilla Firefox Nightly shows teams.microsoft.com intervention enabled.
BUT the actual Teams website has moved to teams.cloud.microsoft.

Could it be that the intervention is not applying to the new URL?

Comment 55

[Andreas Pehrson [:pehrsons]]

(In reply to Dimitrios Apostolou from comment #54)

I have a suspicion. about:compat on my Mozilla Firefox Nightly shows teams.microsoft.com intervention enabled.
BUT the actual Teams website has moved to teams.cloud.microsoft.

Could it be that the intervention is not applying to the new URL?

Right, that makes perfect sense.

Comment 56

[Andreas Pehrson [:pehrsons]]

Attachment: Bug 2000906 - For the Microsoft Teams intervention, add the new cloud URL. r?twisniewski