RFC: multi-tree adapter

[delan]

No description provided.

[delan]

as part of our work on adding accessibility support to Servo, we need a way to combine Servo’s accessibility tree with that of the embedding app, and ideally, combine accessibility trees for webviews and iframes within Servo (#604).

so far, we think the main concrete problem that needs to be solved when combining accessibility trees is ensuring that node ids are globally unique. we think we can do this by making a “meta-adapter” that rewrites tree updates and action requests from the various subtrees, replacing local node ids with globally unique ids.

the meta-adapter would know about the subtrees, where they meet, and which subtree each tree update came from. in exchange, it would expose an Adapter interface for each subtree, bound to that subtree (not yet implemented). internally it would own some concrete Adapter (currently winit in this patch).

this patch is a proof of concept, with only basic rewriting of node ids in tree updates. it does not rewrite action requests yet, nor does it correctly rewrite root node and focused node updates.

(cc @lukewarlow, @alice, @Loirooriol)

[DataTriny]

Thanks @delan and the whole team!

One major issue I can think of with this approach is that each adapter currently have a very different API, so I don't think we could have this meta adapter be "generic" over an inner adapter, at least not in a simple way.

I am also unclear on the performance cost of having to go through this mapping table all the time.

[DataTriny]

I am working on a different approach to solve this. It is almost complete and I hope I can share something with you soon. Thanks for your patience.

[lukewarlow]

I've been looking into a slightly different version of the approach in this PR where the mapping logic stays the same but it's integrated into the existing adapters rather than being a wrapper. Which should fix the issue regarding the API shapes all being different.

Assuming it works out we can push that up and then compare?

[delan]

@DataTriny thanks for proposing the changes in #655!

in the meantime, we’ve pushed our reworked approach to this patch as e89abf40c1873...1679fcf06eac2. as @lukewarlow said, it pushes the logic down from a wrapper adapter to the existing adapters (winit only for now).

while this seems to be a possible approach, we haven’t had a chance to measure the performance with non-trivial trees, and it looks like implementing garbage collection (not present in our original patch) would require us to retain a copy of all parent-child references (implemented), plus a copy of the full contents of all nodes that host a subtree (not implemented). since the consumer crate already has all of that information, we expect that your approach will make more sense.

[DataTriny]

So I've studied this a bit more. The main differences with #655 are:

• Graft nodes don't appear in the schema, looking at a tree update does not give information on where subtrees would be added. This could make it more difficult for tree update producers to embed other subtrees.
• The new crate have to be specific about the adapter it encapsulates: this will probably scale badly given the current state of the AccessKit ecosystem. Platform adapters have different requirements so I don't know if we will ever expose one single API.
• The fact that tree ID management falls on the root tree implementor might bring a security advantage over using UUIDs as it should not be possible for malicious actors to try and swap a subtree with another one by using a same UUID. But I'm not sure if there really is a high risk there, and using UUIDs really make it easy for completely independant implementors to provide subtrees that then get merged in the final accessibility provider.

Overall I think my approach in #655 fits better with the rest of the project, but this PR is still missing pieces. I had to add quite some complexity to make this work and I initially thought that this approach would be simpler, but I think that the TODOs in this PR will also make things harder.

Let me know if there are features contained in this PR that are required by Servo and that would make #655 unpractical over there. Happy to help you move forward on this.