Quick clarification - the I2E specified this tidbit, which was omitted from
the I2S. It applies to both:
* Will this feature be supported on all six Blink platforms (Windows,
Mac, Linux, Chrome OS, Android, and Android WebView)?*
No. This feature is supported on all *desktop* platforms, but *not
supported on mobile platforms*. This is because the prerequisite API of
getDisplayMedia, is currently only available on desktop.
On Wednesday, May 25, 2022 at 9:06:34 AM UTC+2 yoav...@chromium.org wrote:
> Hey Jan-Ivar,
>
> Answers below, but feel free to reach out and we can discuss offline any
> further misunderstandings.
>
> On Tue, May 24, 2022 at 8:19 PM Jan-Ivar Bruaroey <j...@mozilla.com>
> wrote:
>
>> Thanks Yoav for taking the time to get involved with the issues. As you
>> mentioned, #11 is resolved by a PR we're working to merge, which means
>> there are only 2 "points of contention".
>>
>> I noticed performance is absent from your points of contention. which I
>> think reflects great progress made in #17 in just a week, since that was a
>> claim from the Chrome team earlier that I think we put to bed.
>>
>
> I don't think it's an actual point of contention, just an artifact of the
> other disagreements that came up during the discussion of the different
> implementation designs. The reason I didn't bring it up here is that going
> with the more conservative choice of an async API enables implementations
> to make all kinds of performance related tradeoffs, rather than force them
> into specific ones.
>
>
>>
>> #48 was opened just 5 days ago when we discovered Chrome had previously
>> undisclosed needs here (the spec says it cannot fail). It seems early to
>> call this one (unless you're tied to a certain outcome).
>>
>> I find the characterization of people trying to be helpful as "back-seat
>> implementation design" unfortunate, since Chome's claims to the WG were
>> about implementation hardship, claiming few if any actual web developer
>> benefits from their design. I think that sets the terms of conversation to
>> be about implementation, and short of responding with "not our problem, we
>> disagree this is hard to implement", I'm not sure what we could have said
>> that wouldn't be characterized this way.
>>
>
> Apologies, but there's a difference between making helpful suggestions
> about implementation options and second-guessing another implementer's
> choices, characterising them as inferior
> <https://github.com/w3c/mediacapture-region/pull/47#discussion_r877104764>.
> At some point, the best way to prove that some implementation choices are
> better than others is using a competing, better implementation.
>
>
>>
>> I'm concerned that what Chrome would ship would not be what ends up being
>> standardized, given how issues are progressing.
>>
>
> If what ends up being standardized and cemented by multiple
> implementations is different from what ships in Chromium, I'm confident
> Chromium would align its implementation to the standard, following other
> implementation's footsteps. Making conservative and future compatible
> choices (such as an async API that can fail) would help us make that
> switch, if needed.
>
>
>> This is not the same state we found ourselves in earlier, since some
>> issues have been solved and others found. Since a major customer voiced in
>> #17 they were open to any of the proposed spec alternatives,
>>
>
> I think you may want to re-read that comment
> <https://github.com/w3c/mediacapture-region/issues/17#issuecomment-1134934556>.
>
> It essentially says that the developer constituency of this particular
> feature doesn't share your views on the issues with async APIs, nor about
> the confusion that call failures may cause them.
>
>
>> it seems odd that the Chrome team is holding on to what amounts to minor
>> design aspects
>>
>
> I can say the same about other participants in that debate. The Chrome
> team in this case has an implementation of the feature that's going for it,
> during which they thought long and hard about the tradeoffs of the various
> approaches.
>
>
>> they've been unable to defend or demonstrate much web developer benefit
>> from.
>>
>
> Avoiding repeating the same argument over and over again out of respect to
> everyone's time does not constitute "inability to defend".
>
>
>
>
>> On Tue, May 24, 2022 at 5:46 AM Yoav Weiss <yoav...@chromium.org> wrote:
>>
>>> After carefully studying the discussions on the various threads (as well
>>> as participating in them, trying to bridge the gaps), my previous LGTM
>>> still stands.
>>>
>>> I believe there are 3 points of contention:
>>> * API shape esthetics
>>> <https://github.com/w3c/mediacapture-region/issues/11> (#11)
>>> * Async nature of CropTarget minting
>>> <https://github.com/w3c/mediacapture-region/issues/17> (#17)
>>> * Whether CropTarget minting should be able to fail
>>> <https://github.com/w3c/mediacapture-region/issues/48> (#48)
>>>
>>> On API shape esthetics, we've managed to reach a reasonable compromise
>>> that's being defined in #50
>>> <https://github.com/w3c/mediacapture-region/pull/50>. Please make sure
>>> that we're shipping the shape defined there, as well as that the PR itself
>>> lands at some point.
>>>
>>> As for the need for async minting and their potential failure, I tried
>>> to clarify the processing model in #47
>>> <https://github.com/w3c/mediacapture-region/pull/47>. It'd be great if
>>> we can land those parts in the spec as well.
>>> At the same time, the discussions on #17 and #48 don't seem to converge,
>>> and revolve mostly around back-seat implementation design, which IMO is
>>> somewhat out-of-place for a WG discussion.
>>>
>>> Going with an *async API that can fail* is justified given the
>>> implementation experience we have so far for this feature, and seems like
>>> an overall more *conservative future-compat choice*, as we can go back
>>> on either of those decisions if future implementations prove that either or
>>> both of those characteristics are not needed. It also seems like these are
>>> not
>>> issues that web developers that used the feature as part of its Origin
>>> Trial deem critical
>>> <https://github.com/w3c/mediacapture-region/issues/17#issuecomment-1134934556>
>>> .
>>>
>>>
>>>
>>> On Thu, May 5, 2022 at 10:09 PM Yoav Weiss <yoav...@chromium.org> wrote:
>>>
>>>> Hey Jan-Ivar,
>>>>
>>>> Apologies, as I missed the recent activity on issue 11
>>>> <https://github.com/w3c/mediacapture-region/issues/11#issuecomment-1112514784>
>>>> before
>>>> LGTMing. I'll re-review in that light.
>>>>
>>>> On Thu, May 5, 2022 at 9:22 PM Jan-Ivar Bruaroey <jbru...@mozilla.com>
>>>> wrote:
>>>>
>>>>> Hi Youav, the WG is making progress in
>>>>> https://github.com/w3c/mediacapture-region/issues/11#issuecomment-1112514784
>>>>>
>>>>> with good feedback from other Google folks. This progress suggests a
>>>>> likelihood the WG will go a different direction here, which means Chrome
>>>>> shipping now would most likely create a web compatibility headache. Can
>>>>> it
>>>>> be held off a month to resolve this?
>>>>>
>>>>> The referenced TAG meeting notes, say it's "*Not the TAG's job to
>>>>> pick a winner*" which seems to conflict with a LGTM. The WG is making
>>>>> progress, so it seems premature to expect the TAG to call disputes, which
>>>>> it sounds like they're saying. Also:
>>>>>
>>>>> 1. The statement *"interoperability is an imperative ... not what
>>>>> is most technically pure"* seems out of place wrt Origin trials.
>>>>> If interoperability with an Origin Trial is now a thing, it's an
>>>>> argument
>>>>> to stop having them.
>>>>>
>>>>> I don't think anyone is arguing in favor of interoperability with the
>>>> existing Origin Trial.
>>>>
>>>>
>>>>>
>>>>> 1. Web APIs are forever. If we can't consider "technical purity"
>>>>> of a brand new API ahead of shipping, then when?
>>>>>
>>>>> 2. The statement *"a lot of elements not visible... these make no
>>>>> sense to set a crop target on"* — means the current API is
>>>>> misleading: The "target" construct (which isn't "set") has nothing
>>>>> inherently to do with cropping, but is merely solving the sub-problem
>>>>> of
>>>>> passing an element from a different realm into the track.cropTo()
>>>>> method.
>>>>> As discussed in #11 better ways would be to reuse element.id or a
>>>>> new element.weakRef serializable interface.
>>>>>
>>>>> Finally, the absence of any argument that the present API is better in
>>>>> ANY respects for web developers, should cause pause. All arguments I've
>>>>> heard instead seem centered on what's easier for browsers to implement
>>>>> (where "easier" subjectively seems tied to choices the Chrome
>>>>> implementation has made). Better API shapes are on the table, and
>>>>> no-one's
>>>>> arguing they're unimplementable.
>>>>>
>>>>> We should do better for web developers here and get the shape right.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> On Monday, May 2, 2022 at 7:16:33 AM UTC-4 yoav...@chromium.org 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 <elad...@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 emailselad...@chromium.org, mfo...@chromium.org,
>>>>>>>>>>>> jop...@chromium.org
>>>>>>>>>>>>
>>>>>>>>>>>> Explainer
>>>>>>>>>>>> https://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 bug
>>>>>>>>>>>> https://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/>.
>>>>>>>>>>>>
>>>>>>>>>>>
>>
>> --
>> .: Jan-Ivar :.
>>
>
--
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/d787822c-891c-43cb-bf41-ef1a222e1382n%40chromium.org.
