1466742 - Application sharing does not work on Windows

Status: RESOLVED WONTFIX

(Core :: WebRTC, defect, P4)

Description

[Adam Ullman]

Go to https://mozilla.github.io/webrtc-landing/gum_test.html on Firefox on Windows and click on the "Application" button

Result: Nothing is shared
Expected result: An application window is shared.

This works fine on Mac OS. Screen and Window sharing also work fine on Windows. It's just Application sharing that does not.

Comment 1

[Andreas Pehrson [:pehrsons]]

I can confirm this on Windows 10. Regression range: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=c7428449&tochange=93c502ef

Must be bug 1341285, the webrtc.org 57 merge.

Dan, could you take a look?

Comment 2

[Ryan VanderMeulen [:RyanVM]]

I find it pretty worrying that this was only discovered now if we're saying it's been broken since Fx56.

Not tracking for 61 at this point since we're getting late in the cycle already and it's not a new regression, but I'm still very-much open to taking a low-risk patch once we find and fix the root cause here.

Comment 3

[Randell Jesup [:jesup] (needinfo me)]

Is this Windows 10 specific?  Also, some windows on Win8 and above and especially win10 cannot be shared.

Application sharing is tough to test in automation; we should add a check of the sharing modes on all OSes to the QA manual test list.

Comment 4

[Dan Minor [:dminor]]

Confirmed that windows that display properly when window sharing do not display when application sharing on Windows 10.

Comment 5

[Dan Minor [:dminor]]

My understanding is that when we implement getDisplayMedia in Bug 1321221 we will no longer support application sharing. :jib, is that correct, and if so, is resolving this bug still a priority? Thanks!

Comment 6

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

I think that's a fair assessment. getDisplayMedia() removes the sharing categories from site control, so sites cannot dictate a certain kind of sharing (window vs. screen vs. application).

This requires new UX for users to pick from a single list of windows and "entire screen", much like Chrome has.

To be clear, there's no technical reason why we couldn't continue to support application sharing, but it's probably the least important and least common, and it might be confusing to users to see their applications listed twice (once as a window, and again as an application).

I propose we defer this feature until there's a compelling use case or need from a partner.

Application sharing exists, as I understand it, for sharing creative tools like Paintshop pro that has a lot of separate toolbar windows. I recommend sharing the entire screen as a workaround for these cases.

Comment 7

[Liz Henry (:lizzard) (relman/hg->git project)]

OK, I'm going to assume this is :jib's call to make, but do you want to check with others on the Product team to confirm? I'll untrack this for 62, for now.
   
We could add something into SUMO to suggest the current workaround (sharing the entire screen), if users are reporting it as a problem.

Comment 8

[Liz Henry (:lizzard) (relman/hg->git project)]

One more question, do we keep telemetry on this feature, so we could take a look to see if users are often trying it and failing in Windows?

Comment 9

[Pascal Chevrel:pascalc (PTO until April 26)]

Updating flags to match what we ship today, I would take a low-risk patch for 63 beta if it doesn't come too late in the cycle. Thanks

Comment 10

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

AFAIK we have no fix planned for 63 or 64. Telemetry suggests application sharing is virtually unused. [1]

Re-exposing it in the upcoming getDisplayMedia (Bug 1321221) would require new work.

[1] https://telemetry.mozilla.org/new-pipeline/dist.html#measure=WEBRTC_GET_USER_MEDIA_TYPE

Comment 11

[Andreas Pehrson [:pehrsons]]

Application sharing will go away and we won't be fixing this bug. See bug 1497559 comment 1.