Come up with a definition for weakRef

[markafoltz]

Both Element Capture and Region Capture make use of a "weakRef" between a RestrictionTarget/CropTarget and its Element, presumably so that the target can outlive its element. The behavior is mentioned in a note,

RestrictionTarget keeps a weak reference to the element it represents. In other words, RestrictionTarget will not prevent garbage collection of its element.

It would improve these specs to:

1. Define weakRef more concretely in HTML and reference that definition; normally garbage collection is outside the scope of HTML
2. See if we can write the spec language in a way to not use weakRefs (can the RestrictionTarget copy whatever data it needs out of the Element when it's created?)

[eladalon1983]

Some background - there were some discussions about using a weak-rf internal slot back when we were working on Region Capture. I originally used something along the lines of "let E be the Element from which T was minted" - so essentially option no2 in your message. But Jan-Ivar and Youenn preferred a weak-ref, and so we landed on that. While I still would have preferred avoding the weak-ref wording, I think by now we have a second argument in favor of it - consistency between the RC and EC specs. I think that leaves us with option no1 as the better long-term alternative.

[markafoltz]

To me, this is an issue to file with the TAG as it is not specific to the problem at hand, and more about how specs should talk about object lifetimes and garbage collection.

[markafoltz]

Shall I file an issue with the TAG on this?

[eladalon1983]

I don't oppose, but I question if it's necessary.

As far as I can tell, the use of "weak reference" and the language discussing garbage collection were both idiosyncratic artifacts of the particular discussion the WebRTC WG editors had at the time. As far as I can tell, specs generally contain internal slots that reference objects, including Transferable objects, and these specs don't normally concern themselves with the implications on garbage collection. (I could be wrong! Open to learning more.)

Possibly we could just amend this language as an editorial change at some later point. Wdyt?

[markafoltz]

It's not necessary if we can figure out how to write the spec in a way that is unambiguous by not referring to undefined concepts in HTML.

Note that the TAG explicitly prohibits APIs from exposing weak references because they make behavior depend on the timing of garbage collection.

https://w3ctag.github.io/design-principles/#js-gc

The way GC is exposed is indirect. If an element is garbage collected, it is no longer renderable, therefore no longer eligible for restriction, and therefore the track stops producing frames. Maybe that's enough to meet the spirit of the rule, if not the letter.

If we lean on the definition of renderable, could we just drop the weak reference concept entirely? That would be simplest.

[eladalon1983]

Wdyt of https://github.com/screen-share/element-capture/pull/57, @markafoltz?

[eladalon1983]

Fixed by #57.