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.
