1756998 - shop.nestle.jp shows slower than Chrome (slow Msaa calls in the parent process)

Status: RESOLVED WORKSFORME

(Core :: Disability Access APIs, defect)

Description

[Olli Pettay [:smaug][[e-mail]]]

See also https://bugzilla.mozilla.org/show_bug.cgi?id=1752764
https://share.firefox.dev/3ISImrE profile shows rather slow Msaa calls in the parent process, causing major jank.
Is there anything we could do to those?

Comment 1

[James Teh [:Jamie]]

This is usually due to one or both of two things:

1. Some a11y client is making a huge number of a11y queries; e.g. crawling the tree or responding to a lot of events.
2. The content process is busy doing something, and since the a11y queries are sync calls from the parent process, that in turn blocks the parent process.

I'm not great at using the profiler, but I don't see huge periods of busyness in the content process that could account for 2) alone. We are sending a sync a11y text change from content and that takes some time, but sync IPDL calls from content still allow incoming a11y calls from parent, so that shouldn't block anything. I guess if the parent process is busy doing other things, that would prevent the content main thread from doing anything other than answering a11y queries until the parent process handles the sync text changed event, which would in turn slow down the whole scenario.

I'd be interested to know whether this problem goes away with accessibility.cache.enabled set to true (needs browser restart). That won't get rid of the sync text change event (yet), but it should prevent a11y clients from blocking the parent process.

Comment 2

[James Teh [:Jamie]]

I can't reproduce any performance problem here with the new accessibility architecture (Cache the World), which is enabled in Firefox 113 by default. Please reopen if the problem persists.