On my system, the WHATWG HTML spec (https://spec.html.whatwg.org/) now takes up to a minute before the page is usable. If I disable caching of the LINKS_TO relation, this goes down to 15 seconds or less. While the HTML spec is an edge case for most users, this worries me a lot because this is time spent building the cache in the content process, which means all users (even those not using screen readers) will be impacted.

Profile: https://share.firefox.dev/3rTjgCD
We're spending a huge amount of time in nsContentList::PopulateSelf, likely triggered by our call to GetElementsByName. What puzzles me is that from what I can see, DOM supposedly caches this info, in which case it should be using the cache rather than computing this repeatedly. If I disable LINKS_TO and then call document.getElementsByName("foo") in the Web Console, this seems to be instantaneous, which suggests that building this once is not particularly slow (and that we must be building it many times instead when caching LINKS_TO).

Set release status flags based on info from the regressing bug 1787282

:morgan, since you are the author of the regressor, bug 1787282, could you take a look?

For more information, please visit auto_nag documentation.

Ah. I misunderstood. DOM caches the node list for each individual name query. It does not maintain a hash of names. GetElementById does have a hash, so it's very fast. I guess name isn't used enough to justify that.

You can reproduce this in the Web Console like this:
for (let i = 0; i < 1000; ++i) { let l = document.getElementsByName("n" + i).length; }
That takes ~10 seconds... and that's just for 1000 names. This document has 55000+ links, so the real number is 55000+! That's a loooong time.

This performance just isn't going to be acceptable for a cache push. I think we're going to need to offload this to the parent process. We already push the link URL as the value for links, so we can get the # reference from that. I think we'll need to walk the entire tree on demand when LINKS_TO is requested, using a pivot to search for links with a matching name or id, similar to how we're handling MEMBER_OF for HTML radio buttons. That seems to be more or less what LocalAccessible ends up doing anyway. Mac doesn't slurp up the entire tree (at least not LINKS_TO), so this will probably be okay. Windows screen readers don't use LINKS_TO.

I haven't A/B tested the performance of this patch w/ what's currently in central, will do that on monday :)

Set release status flags based on info from the regressing bug 1787282

https://hg.mozilla.org/mozilla-central/rev/eecf6f15d069