Default UI for desktop capture is limiting UI developer
Reported by
abhishek...@gmail.com,
Mar 6 2016
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.75 Safari/537.36 Steps to reproduce the problem: 1. Use desktopCapture sample extension provided in Google example Issues a. For window selection it throws its own Picker b. After the selection "Stop" button appears at bottom c. Stop button can be minimized, it is not intuitive to bring it back The above 2 are default UI and behavior from desktopCapture API This is a huge limitation and developer is stuck with this UI and all application looks same! no UI experience developer can bring. What is the point of Web application? What is the expected behavior? The developer should be allowed 1. To show its own selection UI. Instead of throwing a dialog, it should send thumbnails and description of windows to be shown in own html pages. 2. Developer should be allowed show its own stop button. What went wrong? Fixed UI, boring and various UI innovation can not be done. Limiting and at times confusing (can not find stop button). WebStore page: None Did this work before? N/A Chrome version: 49.0.2623.75 Channel: n/a OS Version: OS X 10.11.3 Flash Version: Shockwave Flash 20.0 r0
,
Mar 6 2016
abhishek216: thanks for your feedback. It would make sense to provide some of this flexibility to web developers. Unfortunately I don't think it's possible at this point. It might require a bit of standardization work as well, before it can be implemented. hta: do you know if there are any plans to provide hooks in the API or other APIs that would make it possible to customize this?
,
Mar 7 2016
,
Mar 8 2016
kjellan, nice to see the response, however desktopCapture API is not generic or standard yet. It is one of the way designed currently. I hope chromium team can do in flexible way may be that becomes standard or at least influence standard.
,
Mar 8 2016
We're working on a new revision of the screen share picker, and we appreciate all input from WebRTC users at this point. However, there's huge security risks with giving the web app too much control of how the screen sharing is started/stopped. There's no way we can give a web app access to previews of windows before a user has chosen to share that specific window.
,
Mar 8 2016
,
Mar 28 2016
niklace, You may be correct with respect to security for a web app, however for chrome app or extension, it is already requesting permission form user to access, should not be issue for those app and only if user given the permission before hand? I do not get the whole point of security, even of for web app, once user has allowed.
,
May 13 2016
Late reply. A web app could do it's own stop button that's just a fake button that keeps capturing the screen in the background. You can still have your own button that stops the shared tracks, and then the screen sharing will and and the default stop UI will go away. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by meh...@chromium.org
, Mar 6 2016