W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > March 2022

Re: [mediacapture-region] Refer to getBoundingClientRect as a defintion of the actual crop area (#32)

From: Elad Alon via GitHub <sysbot+gh@w3.org>
Date: Mon, 28 Mar 2022 15:28:39 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-1080798232-1648481318-sysbot+gh@w3.org>
> > ```
> > Let <var>element</var> be the Element from which CropTarget was constructed.
> > ```
> "Let" implies strong reference. Cross-process this messes with GC. We need something to serialize, either in this PR or the other.
> It follows that what we serialize must be a "weak reference" (i.e. not strong). Since this will most certainly be an id in any implementation, "identifier" or "key" would also work, but then we should mention the UA must use a weak map to implement the mapping.

"Let" implies (to me) that it's a local variable that is destroyed when exiting the context - here, this "let" is only valid for the length of the paragraph. No strong reference.

Like "let `kid` be the grandchild who is visiting today; dispense candy to `kid`." This does not imply that the grandchild pointed at by `kid` will be visiting in perpetuity, or that other grandchildren are not coming tomorrow.

> Introduce a slot storing a weak reference to the element.

It might be that using weak references is standard procedure and would be well understood by readers. If that is the case, then I do not wish to delay us further. Could you point out an example of a **Transferable** object that stores a weak reference to an Element in the original context, and where the weak reference gets replicated in the new context?

GitHub Notification of comment by eladalon1983
Please view or discuss this issue at https://github.com/w3c/mediacapture-region/pull/32#issuecomment-1080798232 using your GitHub account

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 28 March 2022 15:28:41 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:19:56 UTC