1756022 - Grammarly native app (not browser extension) causes performance problem on Roll20

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Andrew Overholt [:overholt]]

Steps to Reproduce:

1. Install Grammarly for Windows (https://www.grammarly.com/desktop/windows) (not the browser extension)
2. Create and log in to an account on roll20.net (https://app.roll20.net/login)
3. Close Grammarly for Windows (right-click on panel icon -> Quit Grammarly)
4. Go to a game on Roll20 (they've shared a specific game with us but don't want its URL here)
5. Click and drag the animated game tokens around the board.
6. Re-start the Grammarly desktop application
7. Click and drag the animated game tokens around the board.

Expected Results:

• tokens move around smoothly

Actual Results:

• token movement is very janky
• browser itself becomes largely unresponsive

---

Performance recording (profile)

Profile URL: https://share.firefox.dev/3sLK9Zn

System configuration:

OS version: Windows 10 (Build 19043)
GPU model: Intel Iris Plus Graphics 640
Number of cores: not sure
Amount of memory (RAM): 16 GB

Comment 1

[James Teh [:Jamie]]

Looking at the profile, there are a lot of a11y calls blocking in the parent process. My guess is that we have here yet another instance where an a11y client is doing a lot of crawling through our a11y tree and our current multi-process a11y architecture can't cope.

Grammarly is obviously snooping around in our a11y tree looking for... something. That blocks the parent process due to sync IPC. If our content process is sluggish in any way (I see canvas stuff taking a long time in the content process), that's going to make those sync calls take longer, which of course creates a feedback loop of exponential pain when there are a lot of those calls.

I'd be interested to know if things improve if you set the pref accessibility.cache.enabled to true and restart Firefox. That enables "Cache the World", our new multi-process a11y architecture, which has a primary goal of improving situations like this (since we don't block the parent process).

Comment 2

[James Teh [:Jamie]]

I should flag that accessibility.cache.enabled is months from being ready for daily usage, so please use it with caution. However, it should be stable enough to test something like this.

Comment 3

[Morgan Buck]

I can confirm that setting the accessibility.cache.enabled flag to true seems to resolve the issue at least from a performance perspective.

Comment 4

[Morgan Buck]

Very similar issues appear with NVDA and most other screen readers we've tried. To hold us until Cache the World is ready, do you have any tips on what specific qualities of a page make the a11y tree more easily crawlable? We're also seeking info from Grammarly on their implementation to understand how we can keep it from getting stuck, but it seems like there are so common themes to how the tree is crawled and how crawlers might decide to fallback given a gap in certain information, it seems like there might be some general guidelines Mozilla can provide to help us optimize as much as possible with the current system?

Comment 5

[James Teh [:Jamie]]

Ah, that's interesting. If this is happening with NVDA too, that suggests there are a lot of mutations in the a11y tree, since NVDA doesn't really crawl the tree much unless the tree changes. Either that or there are a few mutations but the content process is really bogged down.

Given that you're testing with screen readers, I assume there is a game that's reasonably accessible? I think I'd need to take a look at it to get a sense of what's happening here, but I'm a blind screen reader user myself, so the help I can give is more limited if the game isn't accessible. Feel free to email me directly if you aren't able to share this publicly.

Comment 6

[James Teh [:Jamie]]

Also, given your findings with NVDA, it's slightly possible Grammarly is not actively crawling the tree, but is just trying to respond to a11y events (i.e. querying elements when they notify of a change) and the content process is bogged down enough that even that causes problems. It'd be good to work out what these a11y events are so we can figure out whether any of them can be optimised away.

Comment 7

[Morgan Buck]

I've emailed a link to an impacted game. I apologize that we've only just begun to do any accessibility work on that application so it will likely be a very poor experience.

Comment 8

[James Teh [:Jamie]]

This is resolved by Cache the World, which is enabled by default in Firefox 113.