feat!: Multiple tree support

[DataTriny]

Adds support for nested trees to the schema and all existing adapters.

Tree updates must now include the tree_id field which indicates to which tree this update applies. The main tree is identified by TreeId::ROOT. Subtrees have to use an UUID (preferrably version 4 to avoid collisions between trees from different sources). The common crate re-exports the Uuid type from the uuid crate, but users will have to enable extra features on the uuid crate in order to generate UUIDs.

Graft nodes are nodes which host a subtree. They are defined by setting Node::tree_id on them. Graft nodes cannot have regular children. They can point to a subtree that does not exist yet. When a graft node is removed or its tree_id property is cleared, its subtree is removed unless another graft node is provided as part of the same update, in which case the subtree is reparented.

The keyboard focus is now determined by starting at the root of the main tree: if the tree-local focus point to a regular node then this node gets the focus, otherwise if the node is a graft then search continues into the subtree.

ActionRequest now uses target_node and target_tree to indicate on which node to apply an action.

Internally, adapters now refer to nodes using a combination of local node ID (provided by the user in tree updates) and tree index. Tree indices are 32 bit unsigned integers that map to TreeIds.

Prior art

In the past we used to use NonZeroU128 as ID for nodes in the schema. We switched to u64 as it's easier to work with in other programming languages and for serialization. However UUIDs are well established and in fact schemars has support for them so this should be less of an issue.

Chromium does not allow nodes to refer to nodes in different trees so it is not possible, for instance, to indicate that a node is labelled by another node that is in a different tree. The same applies here. I don't think it is that useful in practice and it would add a lot of complexity.

Alternative to #641

This design fits into the existing schema and adapter model rather than building on top of it, no conditional compilation required to work with every adapter. It should also be more flexible around tree identification, hopefully allowing completely independant providers to expose their subtree(s) without a central registrar.

[DataTriny]

CC @delan, @lukewarlow

It would be amazing if you were able to give this a try in Servo. I have only performed limited testing to ensure nodes from subtrees would correctly be exposed on Windows, macOS and Linux. Bigger and more complex trees would be needed to validate this.

[delan]

thanks @DataTriny! we’ll need a bit of time to write a minimal accessibility tree builder in Servo, since there is no support for that yet, but we’ll try to test this patch as soon as we can. will update next week :)

[delan]

update: working on it in servo/servo#41173. the combined tree shows up in elevado, but not in accerciser or orca just yet, but that’s almost certainly a bug on our end.