Skip to content
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

Open
jan-ivar opened this issue Jan 22, 2025 · 5 comments
Open

Consider window capture #55

jan-ivar opened this issue Jan 22, 2025 · 5 comments
Labels
enhancement New feature or request

Comments

@jan-ivar
Copy link
Member

§ 5.3 Subroutine: Supported display surface type says the only supported "surfaceType is browser" with this note:

Image

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.

@eladalon1983
Copy link
Member

Glad to hear you support this extension. (It likely goes without saying that I do too.)

it should be simple to add an algorithm to extract the top-level browsing context associated with the viewport captured by either the window

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?

@alvestrand
Copy link

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.

@eladalon1983
Copy link
Member

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.
My thinking is also - if a 1:1 mapping is not explicitly specified, then we can't assume it.
But maybe we can have the spec handle the case where there is a 1:1 mapping, and leave it up to the UA to fail gracefully when there is no 1:1 mapping.

@jan-ivar
Copy link
Member Author

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.

@eladalon1983
Copy link
Member

two tabs start out with different zoom levels, but that seems minor.

That doesn't appear minor to me.

But I also don't see any inherent problem with multiple tabs viewed at once.

The PR should be careful not to assume otherwise. Happy to review.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants