1669801 - The screen share counter from the tray is not working when sharing windows

Status: VERIFIED FIXED

(Firefox :: Site Permissions, defect, P1)

Description

[Daniel Bodea [:danibodea]]

Note

• When the user engages in a WebRTC conference and shares a window, then clicks the screen-sharing icon from the tray/menu bar, he will notice that an incorrect message is displayed.

Affected versions

• Nightly v83.0a1

Affected platforms

• Windows 10
• Windows 7
• Mac OS 10.15

Steps to reproduce

1. Engage in a WebRTC call.
2. Share mic and camera. (irrelevant but normally necessary)
3. Share any window. (not a screen!)
4. Click on the Screen Sharing icon from the tray (bottom taskbar on Windows / top menu bar on Mac OS)

Expected result

• A correct message is displayed.

• Perhaps a similar behavior to the one seen when sharing screens:

  • Case 1: When sharing 1 screen

    "
    Sharing Screen with "<<sharing tab name>>"
    Control Sharing
    "

  • Case 2: When sharing 2 screens

    "
    Sharing Screen with 2 tabs
    Control Sharing on "<<sharing tab name>>"
    Control Sharing on "<< another sharing tab name>>"
    "

Actual result

• An incorrect message is displayed:
  " Sharing Windows with 0 tabs. "

Regression range
This is a new implementation.

Additional notes

• Linux OS does not have this functionality yet.

Comment 1

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

Regression range
This is a new implementation.

I disagree somewhat - we ship these menus on macOS, and have done so for years. They current behave the same way on Nightly as they do on Release. Windows now shares this behaviour.

I admit, however, that the behaviour is pretty broken. I wouldn't call this a recent regression though.

Comment 2

[Emma Zühlcke [:emz]]

It's a bit misleading to the user and could give them the impression they're currently not sharing any screens. So I think we should fix this soon. However, it's not very severe since we have the icon itself, the tooltip on hover and the floating indicator window as an indication of the screen share.

Comment 3

[Daniel Bodea [:danibodea]]

Yes, it appears it is not a recent implementation regression, but an older one, as seen on the Mac OS platform.

I have attempted to find the regressor and these are my results:

2020-10-08T20:12:18.448000: DEBUG : Found commit message:
Bug 1601301, modify browser_devices_get_user_media_in_frame.js to iterate twice, once performing the operation on two same-process frames, and a second time with frames that in fission mode would be in different processes, r=johannh

The observer listening is also modified to listen to notifications from all frames.

Differential Revision: https://phabricator.services.mozilla.com/D56571

2020-10-08T20:12:18.448000: DEBUG : Did not find a branch, checking all integration branches
2020-10-08T20:12:18.453000: INFO : The bisection is done.
2020-10-08T20:12:18.455000: INFO : Stopped

Comment 4

[Daniel Bodea [:danibodea]]

I think it is meant to be blocking bug 1636207 and be regressed by bug 1601301.
Can you confirm, Mike? Also, let me know if the regressor seems incorrect.

Comment 5

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

I was only guessing based on inspection that the regressor was bug 1636207. I trust your mozregression skills!

If this was a pre-existing issue, then it's unclear to me that this should block bug 1636207 - we've been shipping this bug already.

Comment 6

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

Attachment: Bug 1669801 - Fix the shared device menupopup when sharing an application window over WebRTC. r?pbz!

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/fd43210d8d07
Fix the shared device menupopup when sharing an application window over WebRTC. r=pbz

Comment 8

[Alexandru Michis [:malexandru]]

https://hg.mozilla.org/mozilla-central/rev/fd43210d8d07

Comment 9

[Daniel Bodea [:danibodea]]

I have verified this fix on Windows 10, Windows 7 and Mac OS 10.15 with Nightly v84.0a1 and Beta v83.0b4.