W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > February 2022

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

From: youennf via GitHub <sysbot+gh@w3.org>
Date: Wed, 02 Feb 2022 09:18:05 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-1027733095-1643793484-sysbot+gh@w3.org>
> I've made an argument as to why that is a non-issue [here](https://github.com/w3c/mediacapture-screen-share/issues/184#issuecomment-1027049811). It starts with "After all, the user can always select a surface type other than the ideal one..."

What I was meaning is that, as a web developer, I set 'monitor', which is a valid value as per spec/WebIDL, but the picker is not defaulting to 'monitor', or it does but only in specific Chrome versions. Or, as a web developer, I set 'monitor' and getDisplayMedia throws. This would be surprising. As a web developer, I might have to put some specific UI to help user selects the monitor picker, which may depend on the support of the 'monitor' hint or not.

To try summarising the discussions, there are a few options available.
Do you agree with the assessment? Any additional option I may have missed?

1. Use a dedicated DOMString property
Value restricted to application, browser or window in the spec (could be updated to an open enum when WebIDL supports it).

Pros: Easiest to understand. Can be easily extended to additional values (self-tab maybe) in the future. Chrome can extend it to other values, should there be a need.
Cons: No way for web app to identify which hints are actually understood by browser (in particular if we add new values in the future or Chrome adds a proprietary one).

2. Use a constraint based property, reject if value is 'monitor'

Pros: rejection makes it clear 'monitor' is not supported.
Cons: potential compatibility issue if Chrome starts to accept 'monitor'. Adding additional values to the underlying enum might not make a lot of sense (though self-tab may?).

3. Use a constraint based property, ignore if value is 'monitor'

Pros: No compatibility issue like for 2 (but web page cannot learn the hint is ignored similarly to 1).
Cons: Surprising effect that 'monitor', even though valid, is ignored. Adding additional values to the underlying enum might not make a lot of sense (though self-tab may?).

GitHub Notification of comment by youennf
Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/184#issuecomment-1027733095 using your GitHub account

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 2 February 2022 09:18:07 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:19:56 UTC