Re: [mediacapture-screen-share] Revisit: Let getDisplayMedia() influence the default type choice in the picker (#184)

> - The 'monitor' issue

We can throw on `"monitor"` in prose regardless of API (if we decide to), so this seems like a separable discussion.

> - A picker might like hints that reduce the sets of surfaces, or allows reordering them. Say: I prefer secured pages, or I prefer self tab, or I prefer the tab that is playing audio right now, or I prefer the non browser application that just opened me and happens to be code-signed by a related party...

These ideas go further wrt influencing user choice than what I'm comfortable with. They also seem orthogonal to looking at the _[existing]( `displaySurface` constraint passed into _getDisplayMedia_ for a default category to show...

> - It creates some minor backward compatibility issues (either reusing directly the enum, or reusing the whole constraint structure) while I think a hint of this sort should never trigger reject.

I don't see how. [displaySurface]( uses DOMString, not enum, so `{video: {displaySurface: "foo"}}` _cannot_ reject.

> Style speaking (maybe this is just my taste), getDisplayMedia({ audio: true, video: true, prefer: 'window'}) reads better than getDisplayMedia({ audio: true, video: { displaySurface: 'window'} }). Clearer API is better for the web.

I disagree. I'm no fan of constraints, but consistency with getUserMedia wins here in my book.

GitHub Notification of comment by jan-ivar
Please view or discuss this issue at using your GitHub account

Sent via github-notify-ml as configured in

Received on Tuesday, 8 February 2022 00:03:55 UTC