W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > May 2019

Re: [mediacapture-screen-share] Screenshot (still image) capability (#107)

From: guest271314 via GitHub <sysbot+gh@w3.org>
Date: Wed, 29 May 2019 00:49:05 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-496741963-1559090944-sysbot+gh@w3.org>
@jordanaustin 

> The whole goal for this request isn't to find a work-around that developers need to implement in order to inform their users how to use the this feature. 

Have found that creating, if possible, multiple different workarounds provides a means to locate additional bugs in an API, template basic UI's if needed, for the ability to describe how the procedure should ideally work in code.

For example, consider the specific timing of granting of permission to take a screen shot in relation to when the screenshot is actually copied from the screen. 

While trying to reproduce an unrelated bug using `getDisplayMedia()` recorded (using `MediaRecorder`) two versions of the code run with output at `console`. However, instead of the UI being closed before the first image is captured, the permission UI covering a substantial portion of the screen, is captured. Would the user expect the permissions UI to be captured as an image as the first frame? Without trying to create workarounds this screenshot proposal could become an API which captured the permission UI because no workarounds, directly relating to the prospective UI improvements, or related code which presents issues which could affect this screen shot API; that is, making certain that a screen shot does not mean capturing the permission UI as the first frame. What should the UI for a screen shot API look like and do - and not look like and not do?

-- 
GitHub Notification of comment by guest271314
Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/107#issuecomment-496741963 using your GitHub account
Received on Wednesday, 29 May 2019 00:49:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:22:23 UTC