-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider window capture #55
Comments
Glad to hear you support this extension. (It likely goes without saying that I do too.)
Repeating my earlier question - is there some guarantee that a browser window would have a singular active tab? Might it not have 0 or 2 such tabs? |
Multiple tabs viewed at once is not a native Chrome feature, but is available with extensions: https://www.groovypost.com/howto/view-multiple-google-chrome-tabs-split-screen/ It seems that this extension is doing split-screen by manipulating windows on the desktop, so it's possible that the OS and the browser would still see this as multiple windows. Given the number of pages that came up on a simple search for this functionality, it is not inconcievable that such a thing could happen in the future. |
Yes. |
I agree 1:1 is most common by a large margin. But I also don't see any inherent problem with multiple tabs viewed at once. Such extensions or browsers seem free to forward e.g. wheel-based event where it makes sense. The demo already shows users can scroll iframes in a captured page for instance. The only issue might be the two tabs start out with different zoom levels, but that seems minor. |
That doesn't appear minor to me.
The PR should be careful not to assume otherwise. Happy to review. |
§ 5.3 Subroutine: Supported display surface type says the only supported "surfaceType is browser" with this note:
Let's discuss.
It seems to me the spec could easily be extended to cover window capture of same-browser windows, and that this would be just as useful.
This would reveal that the
"window"
displaySurface is in fact a browser window, but this seems relatively harmless.Once #51 is fixed, it should be simple to add an algorithm to extract the top-level browsing context associated with the viewport captured by either the window or browser display surface.
The text was updated successfully, but these errors were encountered: