If we notify the parent process about new child documents before we
notify it of events it is possible the parent process's tree is out of
sync with ours, and doesn't contain the outer doc accessible for the new
document. SO we need to first notify the parent of changes in the
accessible tree for the document, and then we can notify it of new child
documents. We must also make sure when we serialize a subtree that is
being created to not include the sub document or its accessible tree.
We need to implement things like
https://developer.gnome.org/atk/unstable/AtkObject.html#atk-object-ref-state-set
and the same basic thing on windows. That API is fundamentally sync,
but the information necessary to implement it is only available in the
child process. That seems to leave us with two options, either we can
use sync ipc or we can use async ipc but spin a nested event loop. If
we were to spin nested event loops we'd have to be careful to make sure
a11y didn't do anything until the nested event loop was done, and then
a11y would have to deal with whatever changed. I'm not sure that will
work, and since the system is probably waiting for the accessibility
information anyway I don't think we get much out of spinning the event
loop. So I think its somewhat less bad to use sync ipc here.
Instances of DocAccessibleParent need to behave like any other
ProxyAccessible which means something sensible must happen when we
access these fields of a DocAccessibleParent.
Ehsan Akhgari
Trevor Saunders
Carsten "Tomcat" Book