1691371 - Jitsi screen share issue with Firefox browser

Status: UNCONFIRMED

(Core :: WebRTC, defect, P3)

Description

[kingsleyohia]

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

Steps to reproduce:

Replication:
Step1 Login on Jitsi as a moderator using Firefox. Leave video turned OFF.
Step2 Start any screen share (Application, Window or Tab)
Step3 Click the screen share button to stop screen sharing.
Step4 Notice that although the screen sharing stops on the moderator (Firefox) screen, the previously shared screen stays frozen on the guest screen.

Actual results:

Although the screen sharing stops on the moderator (Firefox) screen, the previously shared screen stays frozen on the guest screen.

Expected results:

Screen sharing should have stopped for the guests. It should not stay frozen on the guest screen.

Comment 1

[kingsleyohia]

To help replicate this issue, I am happy to provide a test Jitsi room and PIN if requested.

Comment 2

[kingsleyohia]

To confirm, this issue is not experienced on Chrome or Edge browsers.

Comment 3

[Mark Banner (:standard8)]

Please don't alter severity/priority flags as this limits getting your bug triaged.

Moving to core/ WebRTC as this seems to be their area of expertise.

Comment 4

[Nico Grunbaum [:ng, @chew:mozilla.org]]

Kingsleyohia, thanks for your bug report! Yeah, setting the severity or priority flags indicates it has been triaged, so we are just seeing this now. This sounds like a bug in the Jitsi web client. I would open a bug in the Jitsi issue tracker. I am going to leave this open for now, to see how that goes. If it isn't on their side the next steps will be trying it in Nightly, and attaching the output of about:webrtc. Thanks again!

Comment 5

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

Step3 Click the screen share button to stop screen sharing.

Which button do you mean? A button on the jitsi page, or a Firefox-specific UI button?

If it's the former, then I can confirm that browsers vary slightly here. With https://jan-ivar.github.io/dummy/gdm.html after typing video.srcObject.getVideoTracks()[0].stop() into web console, I see the following:

1. Chrome/Edgium switches to black
2. Safari switches to white (background color)
3. Firefox freezes on the last frame.

If it's the latter, then bug 1615282 may also be involved.

Comment 6

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

I should clarify, regardless of these differences, web sites should be handling this. Though there's a chance the site are relying on https://crbug.com/941740 here.

Comment 7

[guest271314]

Attachment: Screenshot_2021-03-04_06-54-46.png

Screen sharing should have stopped for the guests. It should not stay frozen on the guest screen.

There is no mention of "black frames", used twice in https://www.w3.org/TR/mediacapture-streams/ and no specified requirement to set the last frame as a "black frame" that the user did not deliberately add to the track.

The specification https://w3c.github.io/mediacapture-screen-share/ uses the term "stop" once

In addition to feedback mechanisms, a means to for the user to stop any active capture is advisable.

Setting enabled attribute of MediaStreamTrack to false prior to stopping the stream should achieve the requirement.