Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

Loosen window capture restrictions on Wayland #1355

Closed
Martmists-GH opened this issue May 1, 2024 · 8 comments
Closed

Loosen window capture restrictions on Wayland #1355

Martmists-GH opened this issue May 1, 2024 · 8 comments
Labels

Comments

@Martmists-GH
Copy link

Operating System

Arch Linux

XDG Desktop Portal version

1.18

XDG Desktop Portal version (Other)

No response

Desktop Environment

KDE

Desktop Environment (Other)

No response

Expected Behavior

OBS keeps a reference to the previous window title/application and captures it when it becomes available

Current Behavior

Currently, window capture in OBS opens a popup for every window, instead of remembering the last known application like it does on X11.

Steps to Reproduce

  1. Launch OBS
  2. Add a window capture source
  3. Restart OBS

Anything else we should know?

In the OBS community they said it was a Wayland issue, on the Wayland git they said it was an application or compositor issue. The OBS maintainers said it was an issue with xdg-desktop-portal.

See also:

@github-project-automation github-project-automation bot moved this to Needs Triage in Triage May 1, 2024
@Mikenux
Copy link

Mikenux commented May 1, 2024

Hello @Martmists-GH!

I think the first improvement is to have what is needed in the portal so that we only have one session restore window instead of multiple ones, while still being able to be selective in what is restored.

Regarding the behavior you expect, there is the following issue: #1064.

@Martmists-GH
Copy link
Author

I think rather than avoiding multiple windows, being able to restore automatically without a window would be much more beneficial.

@Mikenux
Copy link

Mikenux commented May 2, 2024

Don't forget the other issue I mentioned which is about window tracking 😉.

In this issue, it's about the user defining which specific windows (using their titles) to track. The same can be done for session restore (at least for windows), but we ask again when the session has changed (e.g. a new source has been added) to protect against the app possibly recording windows that we removed from sources (since sources are not removed with the portal).

@Mikenux
Copy link

Mikenux commented May 4, 2024

Mistakes here from me.

In GNOME, currently, the portal asks only when relevant windows are no longer available. Making them available before launching OBS restore the corresponding sources automatically. I think that makes sense as a way to handle removed sources. If the behavior you described concerns OBS not automatically restoring the session when launched while the corresponding windows are still available, this seems to be a bug which is apparently recognized in the kde bug you linked.

If you want to restore the session when OBS is running and the corresponding windows become available (i.e. during the session they were closed but you reopened them), the only way is to explicitly ask which sources to track, and to be clear on how to remove this tracking (removing source tracking can't be done within app UI). This issue is then the same as #1064 as I already said.

@YellowOnion
Copy link

The issue is that OBS wants to save sessions and instantly restore them, with possible multiple different windows being captured at once, this needs to persist between restarts of the compositor, it seems quite difficult to do this without the client providing UUIDs for each different "kind" of window, that the window manager can match against, and then provide a handle for OBS, that can be persisted to disk by the compositor.

It's quite hard to match against windows for example, inside sway for auto placement, most windows within an app look pretty similar except for a transient handle provided, and extremely fickle title that changes based on all sorts of random decisions by the app designer...for example you might want to capture a firefox session with a specific user or profile that you can use safely for recording, but the title can and will change due to any arbitrary website's choice, it's not at all secure.

I would go as far to say it needs a wayland extension to provide metadata that can establish some concrete metadata to match against.

@jadahl
Copy link
Collaborator

jadahl commented Jun 14, 2024

I would go as far to say it needs a wayland extension to provide metadata that can establish some concrete metadata to match against.

That would probably be https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/238 .

Perhaps a portal backend could automatically add any window from a previous saved session that would be restored if it was available when the restored session was created.

@Mikenux
Copy link

Mikenux commented Jun 17, 2024

you might want to capture a firefox session with a specific user or profile that you can use safely for recording, but the title can and will change due to any arbitrary website's choice, it's not at all secure.

What do you mean by "use safely for recording" and "not at all secure"? If you're worried about recording wrong content, note that the content of a website or window can also change. For a secure recording, that is a recording that the app is not going to share, you need a fully (and truly) sandboxed app. However, it's a different story for streaming.

@swick
Copy link
Contributor

swick commented Oct 9, 2024

Not a bug, but a feature request. Maybe convert this to a discussion.

@flatpak flatpak locked and limited conversation to collaborators Oct 9, 2024
@GeorgesStavracas GeorgesStavracas converted this issue into discussion #1458 Oct 9, 2024
@github-project-automation github-project-automation bot moved this from Needs Triage to Triaged in Triage Oct 9, 2024

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
Projects
Status: Triaged
Development

No branches or pull requests

5 participants