Just to (belatedly) update this thread: Following a discussion with the API owners and the intent owner a few weeks back, they are planning to try and get more folks to weigh in on the open issues, and hopefully break the tie.
On Wednesday, March 23, 2022 at 6:28:30 PM UTC+1 Elad Alon wrote: > It may be better to ask actual web developers regarding the least >> confusing option amongst those proposed. > > > The Web-developers I am in contact with are happiest with CropTarget. One > of them has mentioned that on issue #18 > <https://github.com/w3c/mediacapture-region/issues/18>. > Other Web-developers have not shown up with a preference one way or > another. > > It bears mentioning that we have been discussing the API in the WebRTC > Working Group for approximately 14 > <https://docs.google.com/presentation/d/1crumgYj4eHkjo04faLktPTg0QoYJhTFoosEBudfJBuw/edit#slide=id.g7954c29f8a_2_0> > months > <https://docs.google.com/presentation/d/1crumgYj4eHkjo04faLktPTg0QoYJhTFoosEBudfJBuw/edit#slide=id.g7954c29f8a_2_0>. > > The initial name for this part of the API was CropID. It was changed > <https://github.com/w3c/mediacapture-region/commit/a60b62cb8946d2c6f79de57ff54bb8cd2a0b8550> > to > CropTarget ~4 months ago, following discussions in the WG. Youenn filed issue > #18 <https://github.com/w3c/mediacapture-region/issues/18> ~2 months ago. > During those two months, no WG member, browser-implementer or Web-developer > voiced concerns about the "CropTarget" name. Youenn has made several > suggestions (Viewport, LayoutBox). I believe I have addressed these > suggestions. I do not think there is interest in the WG for changing the > name. I think the name CropTarget will end up sticking, and not produce a > compat risk. > > Sync vs. async cropTarget creation seems like something you'd want to >> decide on before shipping. > > > It is something we have tried reaching consensus on. But I am not > observing convergence. I proposed the following: > > - For Chrome, it is important to use a Promise<CropTarget>. > - For any browser that does not feel a Promise is necessary, they can > immediately return a pre-resolved Promise<CropTarget>. > - Web-developers would be virtually unaffected by the addition of a > Promise even - for the sake of argument - if it isn't strictly necessary. > (I still think it is necessary.) > > You mentioned on the thread that the browser can refuse to mint new >> cropTargets in some cases. What happens then? Is it specified? How are >> developers supposed to defensively program their API use against that? > > > Failure to mint additional tokens happens if excessive tokens are minted. > (Defends against memory-overuse in the browser process.) > Failure is reflected by a Promise being rejected rather than fulfilled - > which is an established pattern and well-understood by Web-developers. > > > If minting couldn't fail, then (naively) writing the >> process/origin<->token mapping in the browser process could've been done >> async, while the creation of the token could be sync. > > > That is an interesting alternative; thank you for suggesting it. I have > given it thought, and I see some issues with it. To start with, an > application could be given a "dead" token. Such a token will never be > useful, but the application would not be able detect that until it calls > cropTo(token), and that call fails. Then, this failure would only be > detected by inspecting the error returned by cropTo(). But note that often, > produceCropTarget() and cropTo() are called by different documents, so now > we even need to postMessage() back a message that "your call to > produceCropTarget didn't really work, you have a dead token." > > So, if minting itself fails, that's preferable in two ways: > > 1. The failure is recognized closer to the actual point of failure. > (And detected by the concerned entity.) > 2. The application might even wish to *forego calling > getDisplayMedia()* if it knows it's got a bad token (or rather - no > token). > 3. The application is *not* left holding a "dead" token. Instead, it > holds a rejected Promise<CropTarget> - an established pattern for failed > async-construction. > 4. If the conditions that caused minting to fail change, then it's > clear that calling produceCropTarget() again might work. (Whereas a dead > token raises a question - is it *now* OK to use, or should we produce a > new > non-dead token?) > > Does that make sense? > > This seems mostly like a developer ergonomics question. As such, (and like >> above) a signal from web developers could go a long way to break the tie. > > > One of my partners from Google Slides has commented > <https://github.com/w3c/mediacapture-region/issues/11#issuecomment-1076543965> > as > much. She prefers the approach we took - MediaDevices.produceCropTarget. > (No Web-developers have mentioned a preference for the other approach - > Element.produceCropTarget.) > > On Wed, Mar 23, 2022 at 7:01 AM Yoav Weiss <yoavwe...@chromium.org> wrote: > >> >> >> On Monday, March 21, 2022 at 9:15:21 PM UTC+1 Elad Alon wrote: >> >>> P.S: Requesting to ship gaplessly. >>> >>> On Monday, March 21, 2022 at 9:13:30 PM UTC+1 Elad Alon wrote: >>> >>>> Contact emailselad...@chromium.org, mfo...@chromium.org, >>>> jop...@chromium.org >>>> >>>> Explainerhttps://github.com/w3c/mediacapture-region/blob/main/README.md >>>> >>>> Specificationhttps://w3c.github.io/mediacapture-region/ >>>> >>>> Summary >>>> >>>> We introduce a performant and robust API for cropping a self-capture >>>> video track. (Recall that applications may *already* video-capture the tab >>>> in which the application is run using getDisplayMedia(). Using our new >>>> Region Capture, such an application may now *crop* that track and remove >>>> some content from it; typically before sharing it remotely.) >>>> >>>> >>>> Blink componentBlink >>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink> >>>> >>>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/710 >>>> >>>> TAG review statusNot applicable >>>> TAG was positive: "Thank you for bringing this to our attention, and we >>>> are happy to see this proposal move forward." >>>> They did suggest a change of name (Region Capture -> Tab Region >>>> Capture), but that does not affect the API. This proposal to refine the >>>> name will be brought up with the WG. >>>> >>>> Risks >>>> >>>> Interoperability and Compatibility >>>> >>>> Remaining open issues with Mozilla and Apple: >>>> >>> >> Thanks for summing up the open issues! :) >> >>> >>>> - The name "CropTarget" - see >>>> https://github.com/w3c/mediacapture-region/issues/18. No >>>> alternative has yet been presented which garnered more support than >>>> "CropTarget". This seems unlikely to change. >>>> >>>> It may be better to ask actual web developers regarding the least >> confusing option amongst those proposed. >> In the past I've used Twitter polls and developer surveys for that >> purpose. Is this something you considered? >> Maybe devrel folks can help on that front. >> >>> >>>> - Whether produceCropTarget should return a Promise<CropTarget> or >>>> a CropTarget - see >>>> https://github.com/w3c/mediacapture-region/issues/17. In internal >>>> discussions we have consensus that returning a Promise is preferrable. >>>> However, if the WG settles on returning a CropTarget directly, a >>>> migration >>>> plan would be needed to ensure Web applications are not broken. This >>>> would >>>> be easier if such a change is either not made at all, or is made in >>>> concert >>>> with the next bullet-point. >>>> >>>> Sync vs. async cropTarget creation seems like something you'd want to >> decide on before shipping. You mentioned on the thread that the browser can >> refuse to mint new cropTargets in some cases. What happens then? Is it >> specified? How are developers supposed to defensively program their API use >> against that? >> If minting couldn't fail, then (naively) writing the >> process/origin<->token mapping in the browser process could've been done >> async, while the creation of the token could be sync. >> >> >>>> - API surface of produceCropTarget - see >>>> https://github.com/w3c/mediacapture-region/issues/11. We want >>>> MediaDevices.produceCropTarget(), whereas Apple wants >>>> Element.produceCropTarget or possibly Element.cropTarget(). Should the >>>> WG >>>> settle on Apple's current preference, migration would be very easy, as >>>> we >>>> can first expose on the new surface *in addition* and then deprecate >>>> the >>>> old surface gradually. Moreover, such a migration would actually have >>>> the >>>> potential of making a (Promise<CropTarget> -> CropTarget) migration >>>> simpler, should such a change also be adopted by the WG. >>>> >>>> This seems mostly like a developer ergonomics question. As such, (and >> like above) a signal from web developers could go a long way to break the >> tie. >> >>> Other topics under discussion mostly deal with changes to spec-language, >>>> and will not affect the shipped API. Exception - serializability, but that >>>> wouldn't break Web-apps (since it's mostly opaque to the application, >>>> which >>>> would typically only postMessage the CropTarget and use it on the other >>>> side). >>>> >>>> *Gecko:* No signal ( >>>> https://github.com/mozilla/standards-positions/issues/621) See above >>>> clarification about remaining open issues under discussion. >>>> >>>> *WebKit:* No signal ( >>>> https://lists.webkit.org/pipermail/webkit-dev/2022-March/032157.html) See >>>> above clarification about remaining open issues under discussion. >>>> >>>> *Web developers:* Strongly positive This work saw strong support from >>>> Web developers inside of Google (Meet, Docs, Slides). >>>> >>>> Other signals: >>>> >>>> Ergonomics >>>> >>>> N/A >>>> >>>> >>>> Activation >>>> >>>> Unchallenging to use. >>>> >>>> >>>> Security >>>> >>>> This is a mechanism by which an application purposefully strips away >>>> information which it already has access to (via pre-existing mechanisms >>>> such as getDisplayMedia). >>>> >>>> >>>> WebView Application Risks >>>> >>>> N/A >>>> >>>> >>>> >>>> Debuggability >>>> >>>> - >>>> >>>> Is this feature fully tested by web-platform-tests >>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>>> ?No >>>> >>>> Flag nameRegionCapture >>>> >>>> Tracking bug >>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1247761 >>>> >>>> Launch bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1168076 >>>> >>>> Sample linkshttps://w3c.github.io/mediacapture-region/demo/ >>>> >>>> Estimated milestones >>>> OriginTrial desktop last 101 >>>> OriginTrial desktop first 98 >>>> >>>> Link to entry on the Chrome Platform Status >>>> https://chromestatus.com/feature/5712447794053120 >>>> >>>> Links to previous Intent discussionsIntent to prototype: >>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/dib14W1B0Xc >>>> Intent to Experiment: >>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/yFUX0KfuUlo >>>> Intent to Extend Experiment: >>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/ZqndGb9e1wM >>>> >>>> >>>> This intent message was generated by Chrome Platform Status >>>> <https://chromestatus.com/>. >>>> >>> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/89fc0404-32ae-4baf-a1c5-64db6e407650n%40chromium.org.
