Avoid showing dialog for screenshare request

[santoshmahto7]

I have encountered a use case where avoiding screenshare dialog will help to run apps elegantly. So I am raising this as bug to start discussion about this and collaboratively figure out if it is possible for portal implementation to avoid showing screenshare dialog.

Here is background of its requirement
Chromium webrtc screenshare feature on linux/wayland is based on screenshare portal api call which works but dialog UI are messy. Chromium itself has its own implementation of dialog to choose either screen/window/tab and make sense since it also allow selecting tab sharing in same dialog. But while sharing, screenshare portal dialog also shows up and we have two dialog for screenshare and creates ambiguity. Hiding/Adjusting chromium dialog has been denied since it also supports tab sharing

Hiding portal dialog will solves this UI issue, So I was wondering if this is worth considering. Please comment your views on this.

Another consideration related to this is that portal api are not only used from sandbox applications to bypass sandbox but also
used by non sandbox application to target many desktop environment. e.g I can call portal api to launch FileChooser and code will work for both gtk and kde seamlessly. So Is it possible to avoid extra dialog for those non-sandbox application as those already have full access to system

[grulja]

As someone who has been recently trying very hard to improve the situation in Chromium, I share your concerns. However, you cannot compare FileChooser with ScreenCast as with FileChooser you still require a user interaction. The reason why it's done this way is mostly to improve security. On X any app was able to get any kind of information, but Wayland has been prototyped with security in mind and with that you cannot easily get screen content without letting the user to know about it.

[santoshmahto7]

As someone who has been recently trying very hard to improve the situation in Chromium, I share your concerns. However, you cannot compare FileChooser with ScreenCast as with FileChooser you still require a user interaction. The reason why it's done this way is mostly to improve security. On X any app was able to get any kind of information, but Wayland has been prototyped with security in mind and with that you cannot easily get screen content without letting the user to know about it.

Yeah FileChooser need user interaction and I mentioned that just to explain things, but dialog can be avoided for screencast request.
I am not favouring to avoid screencast dialog for sandbox application which need approval from user for system access, But we can think of avoiding dialog in case of non sandbox application which anyway has access to whole system.I feel it would be harder decision but would be worth to expand the usage of portal api in non-sandbox application which want to address multiple desktop environment using portal api

[kov]

Have we considered showing a dialog but having a broad "allow everything"? If Chromium could request 'let me grab everything' the portal dialog would only have approve/deny in it, then Chromium could just keep its normal dialog showing all tabs, windows and desktops for the user to select.

[smcv]

See also #324 which asks for a "remember this decision" checkbox, or some way to pre-seed an entry in the permissions store, so that an app does not necessarily have to prompt every time.

[kov]

Both my suggestion and what @smcv mentioned seem to be what Mac OS does FWIW. Application asks for broad access at startup, decision is remembered. Pre-seeding would be nice, but may be hard to audit I guess?

[GeorgesStavracas]

The description of this issue makes it somewhat of a duplicated of #324, but what is being asked is being tracked #800. The plumbing for storing screensharing sessions is in, @grulja has been working on #800 for the rest. So let's continue tracking this on #800 since it's where most of the relevant discussion is happening.