- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Tue, 23 Mar 2021 21:34:28 +0000
- To: public-webrtc-logs@w3.org
> Name: I think the concerns raised with browsing context apply equally to tab. This is much more narrow-scoped than a tab. @annevk I think this is a case where "tab" is narrower-scoped than page, because a page may have a _much_ larger surface area, and we only want to capture what the user sees at the moment. That is: the intersection of the top-level browsing context's _viewport_ and the rendering boundaries of the requesting document, _including_ any content overlaid by CSS (i.e. excluding any content 100% occluded by CSS at the moment): <img width="500" alt="image" src="https://user-images.githubusercontent.com/3136226/112217897-6f93b200-8bf9-11eb-88bf-dabfcba99eb0.png"> ...OR (to complicate matters) depending on the outcome of the [above discussion](https://github.com/w3c/mediacapture-screen-share/pull/148#issuecomment-735982430) on letting an iframe capture its parent: <img width="500" alt="image" src="https://user-images.githubusercontent.com/3136226/112217705-39563280-8bf9-11eb-96a5-cc4319a68652.png"> In either case, this seems best for both privacy and efficiency (we don't want to have to re-render a page for this). If the user scrolls the page they may reveal more info. So I've been calling this *getTabMedia*. Though perhaps *getCurrentTabMedia* is more precise? — In either case, the requester cannot outlive its target, so I wouldn't worry about "tab" implying capture past navigation. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/pull/148#issuecomment-805278486 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 23 March 2021 21:34:30 UTC