Each BrowserParent can host multiple DocAccessibleParents. Nested DocAccessibleParents are in-process iframes. However, there should only ever be one top level DocAccessibleParent.

It seems that during navigation, a new top level DocAccessibleParent can be constructed before the old one is destroyed. I don't know exactly how/why this happens, but it's not entirely unreasonable; destroying an old document should hardly take priority over loading the new one the user just requested.

Currently, this only impacts Windows because Windows needs to get the remote child document when an OuterDocAccessible is constructed in order to send the parent COM proxy. This only seems to be a problem on CI, but when it happens, it is very problematic because the remote document won't send us any events until the parent COM proxy is sent. That results in the test timing out.

Given that the old top level doc is going to die anyway, we can just destroy it when the new one is received.

Assuming I'm correct that this is the cause (and it's hard to be certain given the intermittent nature of this), this should fix bug 1708336, and by extension, bug 1783890.

Otherwise, GetTopLevelDocAccessible() might return the wrong document for a short while.
This causes intermittent problems for Windows tests on CI, as the parent COM proxy might be sent to the wrong document (and thus never sent to the right document).
In this case, the new document will never send events to the parent process, causing the test to time out.

https://hg.mozilla.org/mozilla-central/rev/3e9645a37f5a