Bugzilla

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 IPDL method (perhaps in PContent?) which is called to add additional cache domains that are now required. 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.
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.

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 IPDL method (perhaps in PContent?) which is called to add additional cache domains that are now required. 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.

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.