Bug 255324 – Screen sharing stream is always forced to 1920x1080 with letterboxing regardless of the source size

• Component: WebRTC
• Status: RESOLVED CONFIGURATION CHANGED

[Alexander Khovansky]

Created attachment 465861 [details]
Attempting to share a terminal window

Minimal reproduction: https://codepen.io/alx-khovansky/pen/MWPgBZG

This pen just requests `getDisplayMedia()` without any constraints and displays the output as well as reports the acquired track settings and capabilities (where supported).

Press `start` and select a non-16:9 surface to share. A window is probably the easiest but a non-16:9 screen would work too. For example, a 14-inch MacBook Pro.

Expected:
A video that matches the dimensions of the shared window.

Actual:
A video that has a 1920x1080 resolution regardless of the source dimensions and has a black area on one of the sides.

Note: the reported track capabilities contain the actual window resolution.
Another observation: past certain size the stream will have black borders on both sides.

[Radar WebKit Bug Importer]

<rdar://problem/108245927>

This didn't happen for me in Safari 16 but started in Safari 17. I'd say it was introduced with the new screen sharing menu in Mac OS toolbar.

I just came across this after opening a similar ticket related to this issue and some other getDisplayMedia() issues: https://bugs.webkit.org/show_bug.cgi?id=269961

Like comment 2 mentioned, this seems to be a relatively new issue. The new screen sharing menu in the macOS toolbar has honestly just been an unmitigated disaster in terms of buggy behavior. I have nothing but bad things to say about it from a user experience and technical issues perspective.

[Eric Carlson]

Youenn fixed this with his changes for bug 269961