Either m104 or m105. (The Origin Trial is approved until m104, inclusive.) On Mon, May 2, 2022 at 7:46 PM Joe Medley <jmed...@google.com> wrote:
> When do you intend to ship this? 103? > Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com | > 816-678-7195 <(816)%20678-7195> > *If an API's not documented it doesn't exist.* > > > On Mon, May 2, 2022 at 7:55 AM Chris Harrelson <chris...@chromium.org> > wrote: > >> 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 >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-DxUfEeNT4ffftE-d_k5nBVVF2oLNY8W_GP1bRRWBn7w%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/CAMO6jDP-9L-x3bfM687XWBNke_P65R2YT5YeGbhCZRgHyAfUTQ%40mail.gmail.com.
