- From: Elad Alon via GitHub <sysbot+gh@w3.org>
- Date: Mon, 09 May 2022 21:25:17 +0000
- To: public-webrtc-logs@w3.org
> Nice feature! Why isn't Chrome offering it in getDisplayMedia? I thought that's what #170 was for. A colleague of mine is working on it. > I'd say such applications are mistaken. There's no API I know of that allows tight coupling between an app and a tab. For self-capture, the two are one and the same. You might be aware that it's not possible to bring your Meet calls into Docs. If you also choose to capture your own tab, it gets cropped and shared remotely. Multiple parts of this complex experience (which I name as an example) assume that the current tab is captured. What should they do if the user switches to capturing another tab? * Keep transmitting the new video remotely but inform the user it's a different tab? * Break of the capture and ask the user politely to refrain from clicking the share-instead-button again? Multiple challenges arise that could be avoided if the browser did not put up the button. > How is that different from the user navigating the captured tab? 1. We're not going to prevent the user from navigating tabs; I hope the reasons are self-evident. But should we also allow share-this-tab-instead for **any** capturer/capturee pair? Are the two things, navigation and share-this-instead, equally fundemental user rights? 2. When navigation happens inside of a website, e.g. by clicking a link, it's very likely that the next document will again set a capture-handle, and communication can resume. You might be able to keep the same communication channel going. 3. When self-capturing, navigation of the top-level document breaks off the capture. > Features tied to a captured application disappearing when the captured application disappears, seems like it works as intended. Can you rephrase as a problem? > ... > Is anything undesirable about that? Glad to rephrase. Look at it from the point of view of the capturing application **and its developer**. The browser puts this big, shiny, tempting button in front of the user. The user clicks it, and then the app "stops working" (i.e. can still stream the captured content, but not remote-control it anymore). The user doesn't know why. The user blames the app. If the app's developer is upset with the browser, is that unreasonable? Who put up that big shiny button? Was it not... [the browser?!](https://i.kym-cdn.com/entries/icons/original/000/025/957/scoobbb.jpg) > I see no reason for new API surface. We have just started this conversation. Allow me the opportunity to convince you to the contrary. -- GitHub Notification of comment by eladalon1983 Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/223#issuecomment-1121597946 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 9 May 2022 21:25:19 UTC