Open Bug 1794974 Opened 8 months ago Updated 2 months ago

[CTW] Runtime adjustment of requested cache domains


(Core :: Disability Access APIs, enhancement)





(Reporter: Jamie, Unassigned)


(Blocks 1 open bug)


Not every client needs all the information we cache. Screen readers tend to need almost everything, but we know we have millions of non-screen reader clients. As an example, enterprise SSO tools, IMEs for East Asian languages, etc. probably only need role and states. Voice control probably cares about name, role and actions, but not much else.
To improve performance for these clients, we're eventually going to want a way to only cache a subset of info from content a11y trees.

Our CacheDomain concept provides the foundation for this. Broadly, we're going to need to do the following:

  1. We should have a static variable somewhere which specifies the cache domains currently required.
  2. Instead of using CacheDomain::All when sending the cache for new Accessibles, this should be a function which retrieves the static variable (1).
  3. We'll need a new parent -> content IPDL method (perhaps in PContent?) which is called to add additional cache domains that are now required. In the content process, that method will need to update the static variable (1), then walk all documents and all Accessibles, sending a cache update with the newly requested domains.
  4. (3) only works for existing content processes. For new content processes, PContent::ActivateA11y should take an extra parameter specifying the currently requested cache domains. This parameter will be supplied when the parent process requests a11y in the new content process.
  5. There should be a new method in the parent process to request additional cache domains. This method will update the static variable (1) and send the IPDL message (3) to all content processes requesting the new domains.
  6. RemoteAccessibleBase methods should be updated so that if they're called and the required domain is not being requested, they fail and call the method (5) to request the required domain. For example, if RemoteAccessible::BoundsWithOffset is called but CacheDomain::Bounds is not one of the domains we're requesting (2), it should call the method (5) to request CacheDomain::Bounds.
  7. We should decide on a minimum set of cache domains to request and initialise the static variable in the parent process (1) accordingly.
  8. For clients we know about and detect (e.g. NVDA, JAWS, VoiceOver), we may wish to automatically request a larger set of cache domains, rather than having client calls fail (6).
  9. We may need to reorganise cache domains a little for optimal results. For example, some clients might want text but not text attributes, but these are currently both part of CacheDomain::Text.

I'm really hoping we won't need to do this before we ship, but I wanted to make sure I documented my thinking here regardless.

Noting this here so we don't end up trying to figure this out again:
It's possible for a11y to be initialised in content but not parent; see bug 1310833, bug 1312816 and this code. This is not something we really support and should never happen in the real world. (After bug 1312816, this shouldn't even happen in testing.) I don't think we should bother supporting this here.

  • We will enable all cache domains by default when XPCOM a11y is initialised.
    • Our tests expect everything to be available. Updating them all to request different cache domains seems like wasteful work. Also, a11y gets enabled by the platform on some systems, which will mess up the test expectations across different systems.
    • We can then have specific tests which adjust the requested domains to test the switching behaviour.
  • The text string of text leaf Accessibles is currently part of the Text domain. However, the text is actually the Name of text leaf Accessibles and Name is one of the basic things that should probably always be enabled. We will probably need to move the text (but not the attributes, line boundaries, etc.) into NameAndDescription.
You need to log in before you can comment on or make changes to this bug.