1642807 - The last shared screen remains blocked on Jitsi meeting after stop sharing the screen by using the "Stop Sharing" button

Status: RESOLVED INCOMPLETE

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

Description

[Mike Conley (:mconley) (:⚙️)]

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.

Comment 1

[Mike Conley (:mconley) (:⚙️)]

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.

Comment 2

[Tim Spurway [:tspurway]]

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

Comment 3

[Dan Minor [:dminor]]

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

Comment 4

[Dan Minor [:dminor]]

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?

Comment 5

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

While it's true Firefox ends the stream on the last captured frame whereas Chrome ends on a black frame, I think the real issue here is bug 1643472, and that if we fix that my guess is this will fix the jitsi issue.

Comment 6

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

Whoops, I should have tested before opening that issue. Turns out ended is already fired, so I think this is a jitsi bug.

Comment 7

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

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/

Comment 8

[Mike Conley (:mconley) (:⚙️)]

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

Comment 9

[Dan Minor [:dminor]]

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

Comment 10

[Mike Taylor [:miketaylr]]

Thanks for reaching out Dan.

Comment 11

[Dan Minor [:dminor]]

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.

Comment 12

[Raluca Popovici, Desktop QA]

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

Comment 13

[jaya.allamsetty]

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

Comment 14

[Daniel Bodea [:danibodea]]

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.

Comment 15

[jaya.allamsetty]

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.

Comment 16

[Daniel Bodea [:danibodea]]

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.

Comment 17

[Óvári]

Can you please put [jitsi-meet] in the whiteboard? Thank you

Comment 18

[Óvári]

Can you please put [jitsi-meet] in the whiteboard? Thank you

Comment 19

[Raul Bucata]

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

Comment 20

[Calin Tanase]

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)

Comment 21

[Mike Conley (:mconley) (:⚙️)]

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