Consider upgrading ARIA reflection from FrozenArray<> to ObservableArray<>

[domenic]

What is the issue with the HTML Standard?

Given discussions like #10219 and the general problems with mutable FrozenArray<> attributes (see whatwg/webidl#810), I was considering whether we could upgrade to ObservableArray<>. It has some advantages:

• It automatically ensures that element.ariaFlowToElements === element.ariaFlowToElements. And actually, that equality stays true forever; the array object identity never changes, even if the values inside do.

• It allows authors to do convenient code like element.ariaFlowToElements.push(foo).

• The spec might be simpler (not sure), because the getter and setter are generated automatically, and the backing list is always available. The hard part is writing the spec to keep the backing list updated.

I think this would look something like the following:

• Fix Reflected IDL attributes of type FrozenArray<T>? don't create a FrozenArray #10219. Let's say this creates a new hook, "null out".

• For each element, ariaFlowTo has a boolean, "in explicitly-set mode", initially false.

• The spec monitors the DOM for any changes to id=""s which could cause the "gathered from the DOM" set of elements to change. If "in explicitly-set mode" is false, then the spec updates the backing list with the new set of elements.

• The spec monitors the DOM for any changes to aria-flowto="". Those reset the backing list with the gathered-from-the-DOM set of elements, and sets "in explicitly-set mode" to false.

• The "set an indexed value" and "delete an indexed value" hooks:

  • Sets the content attribute to the empty string.
  • Sets "in explicitly-set mode" to true.

• The "null out" hook:

  • Deletes the content attribute.
  • Sets "in explicitly-set mode" to false.

Possible issue: in this version, the backing list holds strong references to the elements. I'm not sure exactly what problems that creates.

Possible issue: at least in the spec, we need to monitor for changes to id=""s, instead of computing lazily. Assuming implementations have a per-spec implementation of FrozenArray<>, this is probably an extra cost. Optimization is definitely possible in a variety of ways, but it's more code to write.

---

I'm not sure there's any implementer appetite for continuing to churn in this space. But I thought I'd mention it and write down the above sketch. /cc @annevk @alice @petervanderbeken.

[annevk]

I think we already have the problem of strong references due to FrozenArray holding strong references. In #8545 @smaug---- felt most strongly about fixing this, but since then Gecko might also have shipped this "leak" or is about to?

As for the overall ask: I suspect WebKit would be okay with aligning here, but not necessarily willing to lead the charge.

cc @rniwa