Limit to tab-capture.

[jan-ivar]

Can Capture Handle be implemented in "monitor" or "window" capture? Nothing in the current text appears to say. Users, however, would probably find this surprising and creepy, so we might want to limit it to "browser" display surfaces explicitly.

[alvestrand]

getCaptureHandle() will return null if the captured application did not set a CaptureHandleConfig, and there is no way to set a captureHandleConfig without being a Javascript context capable of excuting setCaptureHandleConfig.

I don't see the problem.

[jan-ivar]

The problem is the "captured application" isn't well defined, and could mean any (top-level) web document that occupies screen real-estate that is being captured, either from fullscreen capture of browser window capture.

Example 1: If I have a browser widow visible on my desktop with a document that call setCaptureHandleConfig, and the user chooses to share their Entire desktop, then I think we should mandate getCaptureHandle returning null.

Example 2: example 1 with 3 browser windows visible on my desktop with documents that all call setCaptureHandleConfig

[eladalon1983]

I have received feedback from Web-developers who would like us to extend Capture Handle to also work with native app windows. Especially in the case of captured browser windows, this extension makes intuitive sense, as there's at most one active tab per browser window, and the extension of Capture Handle is natural and obvious there - the readable handle would be that of the active tab.

The challenges window-capture-handle would raise should be considered before we mandate that the user agent SHOUD/MAY/MUST offer such an option. And precisely for that reason, the document does not currently offer a way to set a captureHandleConfig on anything other than a tab. But we need very compelling reasons to actively disallow anything, and you have not brought up such reasons[*]. We are not in the business of stifling innovation.

[*] To be fair, you have brought this up:

Users, however, would probably find this surprising and creepy

To that I say - citation needed. It's unclear to me how this would even be noticeable by the user. The capturing application would already be getting every single pixel in the captured window. What difference would the Capture Handle be making? Why would users know that something was telegraphed via the Capture Handle rather than through the pixels?

[eladalon1983]

Shall we close this, @jan-ivar?

[jan-ivar]

Editor's meeting:

• Agreement on PR to say this specification describes mechanism for tab capture only.

[jan-ivar]

My issue here applies equally to both actions and identity, so I've removed categorization. In the future I suggest we discuss categorization at the editors' call.

[eladalon1983]

All of our discussions here proceeded under the assumption that this referred only to Identity. The agreement in the editors' meeting was likewise specific to Identity; we did not discuss Actions.

[eladalon1983]

That said, since we've not adopted Actions yet, I think there's no reason to limit you in editing it. I'm happy approving PR #39 despite its simultaneous editing of Identity (according to our agreement) and Actions (without any discussion). As we were all in agreement, I think you can go ahead and merge.

[jan-ivar]

... since we've not adopted Actions yet,

@eladalon1983 This is incorrect. Both were adopted, that was the compromise. We are to work on them in parallel in the same repo. All PRs are under the W3c process and require the same review process, and I don't have any special allowances for maintaining the Actions document, so please clear your approval if it is based on that mistaken assumption.

[eladalon1983]

... since we've not adopted Actions yet,

@eladalon1983 This is incorrect. Both were adopted, that was the compromise. We are to work on them in parallel in the same repo. All PRs are under the W3c process and require the same review process, and I don't have any special allowances for maintaining the Actions document, so please clear your approval if it is based on that mistaken assumption.

Actions is unofficial. Identity is ED.
That said, I think we should focus on moving forward. You have my blessing to merge that PR, under either interpretation.

To clarify, btw, you have my support in moving Actions to ED. It's up to the chairs to decide if another call-for-adoption is needed or not. If one is sent out, I will support it.

[jan-ivar]

Actions is unofficial. Identity is ED.

That's an artifact from the state of the repo before we froze it to move it to the W3C, and no PRs having been merged against it to fix it. Thanks for spotting it! Both should be "ED" so I'll add a PR to take care of it.

[eladalon1983]

Actions is unofficial. Identity is ED.

That's an artifact from the state of the repo before we froze it to move it to the W3C, and no PRs having been merged against it to fix it. Thanks for spotting it! Both should be "ED" so I'll add a PR to take care of it.

I remember things a bit differently, so please run this by @alvestrand and @dontcallmedom, who I believe were involved in these discussions.

At any rate, shall we merge PR #39 and close this issue?