LGTM3 On Mon, May 2, 2022 at 6:50 AM Mike Taylor <miketa...@chromium.org> wrote:
> LGTM2 > > On 5/2/22 7:15 AM, Yoav Weiss wrote: > > LGTM1 > > Thanks for initiating those discussions. My read of the minutes is that > they consider the async approach to be fine, and don't arbitrate on the > naming questions, other than saying that none of the proposals seem better > than where this API has landed. (and some may add confusion) > As such it seems that going with the API as currently defined doesn't bear > significant interoperability risk. > > > > On Mon, May 2, 2022 at 1:03 PM Elad Alon <elada...@google.com> wrote: > >> The discussions around Region Capture have been brought up with TAG again >> (after their original approval >> <https://github.com/w3ctag/design-reviews/issues/710#issuecomment-1055212077> >> of the design). Here are the minutes from that second meeting: >> >> https://github.com/w3ctag/meetings/blob/gh-pages/2022/telcons/04-25-minutes.md#media-capture-region >> >> On Wednesday, April 20, 2022 at 6:33:52 PM UTC+2 yoav...@chromium.org >> wrote: >> >>> 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 <yoav...@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 emails elad...@chromium.org, mfo...@chromium.org, >>>>>>> jop...@chromium.org >>>>>>> >>>>>>> Explainer >>>>>>> https://github.com/w3c/mediacapture-region/blob/main/README.md >>>>>>> >>>>>>> Specification https://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 component Blink >>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink> >>>>>>> >>>>>>> TAG review https://github.com/w3ctag/design-reviews/issues/710 >>>>>>> >>>>>>> TAG review status Not 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 name RegionCapture >>>>>>> >>>>>>> Tracking bug >>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1247761 >>>>>>> >>>>>>> Launch bug >>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1168076 >>>>>>> >>>>>>> Sample links https://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 discussions Intent 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/CAL5BFfUZueknsW5KhHd0F6-tdSQND_QBCCiD0fyYZ5prGjR2Kw%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUZueknsW5KhHd0F6-tdSQND_QBCCiD0fyYZ5prGjR2Kw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > > -- > 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/7dad6c95-c653-a8d7-d50d-69ab16bdf442%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7dad6c95-c653-a8d7-d50d-69ab16bdf442%40chromium.org?utm_medium=email&utm_source=footer> > . > -- 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/CAOMQ%2Bw-DxUfEeNT4ffftE-d_k5nBVVF2oLNY8W_GP1bRRWBn7w%40mail.gmail.com.
