Note

The last shared screen remains blocked on Jitsi meeting after stop sharing the screen

Affected versions

Beta v77.0b9

Affected platforms

Windows 7
Windows 10

Steps to reproduce
Precond:
privacy.webrtc.allowSilencingNotifications - true
privacy.webrtc.legacyGlobalIndicator - false

Engage in a video conference on Jitsi
Allow the microphone or camera sharing.
Also, start sharing the entire screen.
Click on Stop Sharing button from Global Sharing Overlay.

Actual result
The last shared screen remains blocked on Jitsi meeting after you click Stop Sharing button

Expected result
You should not see the last shared screen if you stop sharing your screen.

Additional notes

This issue was found to reproduce with Jitsi and Windows 10 and 7.
This description might suffer updates before the feature test run is completed.

From dbodea:

To provide more information, the issue occurs when using the "Stop Sharing" button from the "Global Sharing Indicator or when removing the screen-sharing permission from the Site Information panel.
It was also reproduced on Ubuntu 18.04.4LTS and MacOS 10.12.6 by force-closing the screen-sharing permission from the site information panel.
However, it does not occur when stopping screen-share from the Jitsi's "Share your screen" button.
Furthermore, it was also reproduced in Release v76.0.1 so, in its essence, it is not a regression issue, but a previously existing one, however, the
"Stop Sharing" button is a feature implementation that is linked to the permissions panel.
Also found JumpChat web-app to reproduce this issue, both with the "Stop Sharing" button or by the web-apps "Share Screen" button (since it does not appear to have another way to stop the screen sharing).

From pbz:

I don't think this is a (recent) regression. I can reproduce it with Firefox 60 even. Also, when I run the same pattern on Google Meet it works fine.

The frontend seems to trigger the screenshare revoke properly, I can trace the call all the way to getUserMedia:revoke: https://searchfox.org/mozilla-central/rev/9aa7bebfd169bc2ead00ef596498a406e56bbb85/dom/media/MediaManager.cpp#3805

So this is either a bug in Jitsi or in our WebRTC implementation. Moving to WebRTC.

S1 or S2 bugs need an assignee - could you find someone for this bug?

I'll investigate, although this sounds more like an S3 to me.

This reproduces with just https://mozilla.github.io/webrtc-landing/gum_test.html. The screen sharing does stop, but we continue to display the last image captured. When Jitsi's "Share your screen" is used to stop sharing, it switches back to the camera, so there is something to replace the last image.

Maybe we should generate a black frame somewhere when we stop screensharing? Jib, what do you think of this?

Jitsi needs to listen for the ended event on the screen-sharing track on the sending side, which is fired when permission is revoked by the user in the Firefox UX, and then terminate screen-sharing.

FWIW the same event is fired in Chrome if the user is sharing an application window and closes it (bug 1615282).

You can test it here https://jsfiddle.net/jib1/14vts7db/

This sounds like something we should reach out to Jitsi about - let's see if our WebCompat team has contacts there.

I reached out to Jitsi by email and they're experimenting with adding a handler for ended on their side.

Thanks for reaching out Dan.

Jitsi is looking into a workaround on their side. I'm going to keep this bug open because we might want to generate a black frame on our side as a workaround.

This issue is reproducible on Hangouts(Windows 10x64) on Firefox 78.0b8. See this similar issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1646351

This issue has been fixed on http://meet.jit.si.

No, it hasn't been fixed. It is still reproducing just like before. Confirmed on Windows 10 and Mac OS 10.12.6, on Nightly v80.0a1, Beta v79.0b5 and Release v78.0.1.

It has been fixed on https://meet.jit.si. Please note that it doesn't switch to the camera until the page has focus, so you need to click on the page to get camera access again.

From my point of view, the bug still reproduces. At least 2 clicks are needed form the presenter in order for the spectators to stop seeing the last shared screen. Furthermore, if the page is simply killed, the last image remains blocked until restart.

I was not able to reproduce the issue. Stopping a shared screen works as expected:

https://prnt.sc/3exgcASxdc2T
Mike, is the issue still reproducible on your side?

Tested with:

Browser / Version:Firefox Release 100.0.2 (64-bit)/ Firefox Nightly 102.0a1 (2022-05-29) (64-bit)
Operating System: Windows 10 PRO x64

Closing this as incomplete since we didn't get any response from Mike Conley.

Note: I was not able to reproduce this issue either.

Tested on:
Operating system: Windows 10
Firefox version: Nightly 110.0a1 (2023-01-12)

Sorry! This one slipped off my radar. No, I haven't seen this since. INCOMPLETE is the right call.