Closed Bug 1466742 Opened 7 years ago Closed 6 years ago

Application sharing does not work on Windows

Categories

(Core :: WebRTC, defect, P4)

56 Branch
Unspecified
Windows
defect

Tracking

()

RESOLVED WONTFIX
Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 - wontfix
firefox60 --- wontfix
firefox61 - wontfix
firefox62 - wontfix
firefox63 --- wontfix
firefox64 --- wontfix

People

(Reporter: adam, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: regression)

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.
OS: Unspecified → Windows
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?
Has Regression Range: --- → yes
Has STR: --- → yes
Rank: 15
Flags: needinfo?(dminor)
Keywords: regression
Priority: -- → P2
Version: Trunk → 56 Branch
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.
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.
Flags: needinfo?(drno)
Flags: needinfo?(na-g)
Flags: needinfo?(na-g)
Confirmed that windows that display properly when window sharing do not display when application sharing on Windows 10.
Assignee: nobody → dminor
Flags: needinfo?(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!
Flags: needinfo?(jib)
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.
Flags: needinfo?(jib)
Assignee: dminor → nobody
Rank: 15 → 35
Priority: P2 → P4
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.
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?
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
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
Application sharing will go away and we won't be fixing this bug. See bug 1497559 comment 1.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.