1641802 - The Global Sharing Overlay remains displayed when closing the tab with the screen-sharing web-app because of the appearance of the tab-switch-warning

Status: NEW

(Firefox :: Site Permissions, defect, P3)

Description

[Daniel Bodea [:danibodea]]

Note

• When the user shares his screen and then closes the tab with the screen-sharing web-app, the tab-switch-warning will be displayed (incorrectly), leaving the tab somewhat opened, because the other tab wasn't focused due to the appearance of the tab switch warning.
• This issue does not occur if the screen-sharing app is the last tab of the window; another tab is needed, even if it's an about:newtab.
• This issue also does not occur if the other tab from the window has been previously focused while screen sharing (so the tab-switch-warning wouldn't appear).
• The real bad issue here is that the browser is still sharing the screen while the tab is closed! This is really bad from a privacy stand-point.

Affected versions

• Nightly v78.0a1
• Beta v77.0 (RC)

Affected platforms

• Windows 10
• Ubuntu 18.04.4 LTS
• Mac OS 10.15

Steps to reproduce
Required prefs:

• Flip privacy.webrtc.allowSilencingNotifications to true
• Flip privacy.webrtc.legacyGlobalIndicator to false
• Flip privacy.webrtc.sharedTabWarning to true

1. Engage in a conference.
2. Have at least one other tab open.
3. Share your entire screen or the browser window with the WebRTC web-app (It does not matter whether you also share the mic and camera or not).
4. Close the tab with the screen-sharing web-app.

Expected result

• The tab gets closed, the tab-switch-warning is not displayed, the screen sharing stops, the call stops.

Actual result

• Notice that the tab disappears from the window bar, but the content of the page is still focused and ongoing, and also, the tab-switch-warning gets displayed on the other tab from the window and also, the Global Sharing Overlay remains displayed.
• Even after clicking the "Proceed to tab" button so the browser focuses on the other tab, the screen sharing is still ongoing.
• A browser restart is necessary in order to stop the ongoing sharing of the screen (the "Stop Sharing" button from the overlay does not work).

Regression range

• This is a feature issue.

Additional notes

• This issue was tested with Zoom and Talky.

Comment 1

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

This is tricky. So I think there's an ordering issue here.

Normally, when you close a tab, it's contents don't shut down immediately / synchronously. Things like the ongoing WebRTC call might still stay up for a few hundred milliseconds even after you've clicked the "close" button, because we have to communicate to the content process that the tab is going away, and then the content process has to bounce back communications to the parent process to shut down the WebRTC connection, and that all takes time.

Meanwhile, the tabbrowser code says, "Well, technically I'm still sharing the display, so I'd better show the warning".

Probably the worst part here is that we're somehow interrupting the shutdown of the sharing session, and that we need to do a browser restart. I'm not sure why this is happening yet.

What would be ideal is if at the time of the user expressing that they want to close the tab, we immediately tell the WebRTC layer to stop sharing. That probably best matches the user's mental model of what should be happening. I'm not sure how possible that is, but I'll look into it.

Comment 2

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

I see a couple of problems here:

1. Screen capture indicators & tab warning UX never go away on their own
2. The tab warning UX shouldn't have shown up in the first place on close
3. If the tab warning UX hadn't shown up in the first place on close, might JS have captured a glimpse of that tab?

#1 seems most pressing and solvable in front-end.
#2 as well, if we don't care about #3.
#3 might be somewhat serious if it is real, though no worse than today.

I've tried to test if #3 is real, and so far come up short (on macOS):

• I've tried sending capture to another tab over WebRTC (open this in two tabs)
• I've tried storing video in localStorage (open this and run twice)

In both cases: the last frame captured is before the tab cut-over.

Comment 3

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

I agree with your assessment - I had broken down the problems in the same way, and I'm starting with (2) before I look at (1).

I had done a similar test on macOS with Talky, and noticed that the stream ended before the tab switch. I wonder if this will be different from platform to platform - might be worth having dbodea and his team test that out down the line just to see.

Comment 4

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

Will do.

Comment 5

[Tim Spurway [:tspurway]]

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

Comment 6

[Vicky Chin [:vchin]]

Since we have decided to leave this feature pref off I believe this should no longer be set to S1. I do think this is a mustfix if we were to ever decide to pref this on by default.

Will defer to mconley to give it a new severity setting.

Comment 7

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

I agree - the severity can be reset now that we know this is disabled by default.