After bug 493683, changes in aria-labelled/describedby subtrees fire name/description change events on the element being labelled/described. However, this only works if the change occurs in a visible subtree of the aria-labelled/describedby target. If the target is hidden, events aren't fired.

STR (with the NVDA screen reader, though you should get similar results with any other screen reader):

1. Open this test case:
   data:text/html,<button aria-labelledby="label" onclick="label.textContent = 'After change';"></button><div id="label" style="display: none;">Press to change</div>
2. Tab to the button.
3. Press space to activate it.
   • Expected: NVDA should say "After change"
   • Actual: NVDA says nothing.

Impact: This means that the updated label isn't announced by screen readers when selecting a message in a Gmail message list.

I guess we're going to have to watch for DOM changes to handle this, since this isn't handled by layout (since it's invisible) and thus layout doesn't fire a11y notifications.

Without this, the cached name isn't updated when the selection state of an item in a Gmail message list changes.

We already handled this for visible aria-labelledby/describedby subtrees based on a11y events.
However, when a subtree is hidden (whether via CSS or aria-hidden), it is completely removed from the a11y tree, so we can't use a11y events.
Instead, when a node is added to the DOM, we walk its ancestors looking for an aria-labelledby/describedby target.
We stop if the node or an ancestor has an Accessible, since that means it will be handled elsewhere.
This also limits the number of ancestors we walk for each inserted node, thus decreasing the performance impact of this change.
This doesn't catch all possible mutations in a hidden subtree (e.g. removals or direct text node changes), but this at least fixes a case in Gmail.
Given performance risks, I think it makes sense to address specific cases as they arise.

https://hg.mozilla.org/mozilla-central/rev/7a0b7656c363