Re: [mediacapture-screen-share-extensions] Tab capture control (#13)

> I understand the urge to quickly go to API but I think it is a bit premature.

Your previous comment raised specific concerns, and I engaged with them, providing what I believe to be real solutions to real concerns. It would be nice if you could indicate which of these issues were satisfactorily resolved for you.

> There are some design decisions we should take consciously:

The length of the previous comment indicated to me that it was an exhaustive list. I now hear that it wasn't. Is the current list exhaustive, or do you anticipate additional issues?

> Allow/disallow web pages to select specific types of events and not others

No Web developer has yet requested this.
If they do, we can add this capability.

> Understand how web applications will know whether forwarding is working or not

If the promise returned by `captureWheel()` is resolved, forwarding is working, until the capture stops. I don't see any missing information...?

> (my experience so far on Chrome Canari shows this is a real issue)

If you have any issues with Chrome, your bug reports would be most appreciated.
If you have issues with the demo itself, I'd love to fix it - just let me know!

> Whether this is a capture controller thing or a MediaStreamTrack thing (difference in transferability)

To me, it's obviously a `CaptureController` thing. Can you indicate requests from Web developers for this to be used in some manner that could be addressed with `MediaStreamTrack` but not with `CaptureController`?

> Use permissions model or not (this is JS observable so we cannot have one UA do it and not another one)

I believe it is permissible for user agents to differ in their implementation of permissions policies, including prompts. On Chrome, sometimes we get one-time permissions, and that too is JS observable. If there is a problem here, please explain it to me.

> Decide whether setting a specific zoom level should be part of the MVP

It is requested by Web developers. Why should it not be part of the MVP?

> (AFAIK, apps like browsers tend to provide easier access to increment zoom in/out)

Such controls are in the captured app. The entire point of this API is to provide controls in the capturing app, without forcing the user to switch to the captured app.

> Explore Command/+ and Command/- and pinch for zoom

Easily extensible at a later time. No need to delay the MVP on such extensions, which were NOT requested by Web developers. (But please feel free to send a PR if you are interested.)

> Explore what could be translated to native surfaces and what could not be

Any reason for this to be in the MVP?

> Decide whether we should guarantee or not care about captured tab knowing it is captured

Doesn't sound like a blocking issue to me. I'm fine either way.

---

I would really appreciate it if you could:
1. Indicate which prior issues are resolved from your point of view, given the answers I have previously given, and given the changes I have made in response to your earlier feedback.
2. Indicate which issues are consensus-blocking and which are not.

-- 
GitHub Notification of comment by eladalon1983
Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share-extensions/issues/13#issuecomment-2423017040 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 18 October 2024 18:28:21 UTC