State of the Art
The spec currently reads:
The user agent MAY use the presence of the displaySurface constraint and its value to influence the presentation to the user of the sources to pick from. The user agent MUST still offer the user unlimited choice of any display surface. The user agent is strongly recommended to steer users away from sharing a monitor, as this poses risks to user privacy.
That is, we have previously specified that displaySurface can serve as a hint to the user agent about which surface type should be presented most prominently to the user. But we require that all options still be offered to the user.
Chromium has implemented this as follows (try it out):
Basically, Chromium always uses a 3-pane dialog, and the Web can tell Chromium which pane is pre-selected. But the user can always change panes.
But things don't work as smoothly if we want to use the new native macOS picker. It looks like Safari had to contend with a similar issue, and they chose to use a text-heavy dialog, pictured below.
I am not sure Chromium should replicate this approach. With tabs thrown into the mix this becomes a three-option dialog, requiring multiple clicks and a lot of reading.
Solution?
We should consider moderating the spec language here, allowing the hint to be taken as an instruction. That is, UAs should be free to only offer the type of surface (tabs/windows/screens) that the app requests. For non-malicious Web apps, this allows the UX question to be delegated to the Web-app, potentially saving a click.
One might object that this allows the user to be "pushed" to share a screen, compromising their privacy/security. But I'd argue back that such pushing is already possible, as the Web app can just stop() the tracks if the user chooses anything but the screen, the forcefully suggest the user try again.
State of the Art
The spec currently reads:
That is, we have previously specified that
displaySurfacecan serve as a hint to the user agent about which surface type should be presented most prominently to the user. But we require that all options still be offered to the user.Chromium has implemented this as follows (try it out):
Basically, Chromium always uses a 3-pane dialog, and the Web can tell Chromium which pane is pre-selected. But the user can always change panes.
But things don't work as smoothly if we want to use the new native macOS picker. It looks like Safari had to contend with a similar issue, and they chose to use a text-heavy dialog, pictured below.
I am not sure Chromium should replicate this approach. With tabs thrown into the mix this becomes a three-option dialog, requiring multiple clicks and a lot of reading.
Solution?
We should consider moderating the spec language here, allowing the hint to be taken as an instruction. That is, UAs should be free to only offer the type of surface (tabs/windows/screens) that the app requests. For non-malicious Web apps, this allows the UX question to be delegated to the Web-app, potentially saving a click.
One might object that this allows the user to be "pushed" to share a screen, compromising their privacy/security. But I'd argue back that such pushing is already possible, as the Web app can just
stop()the tracks if the user chooses anything but the screen, the forcefully suggest the user try again.