1796162 - Poor initial performance for a few seconds on the "Nvidia GPU cards wikipedia.com page" with NVDA enabled

Status: NEW

(Core :: Disability Access APIs, defect)

Description

[Rares Doghi, Desktop QA]

Attachment: 2022-10-19_18h04_35.mp4

Found in

• 108.0a1 (2022-10-18)

Affected versions

• Firefox Nightly 108.0a1
• Beta 107.0b2
• Release 106.0

Affected platforms

• Windows

Steps to reproduce

1. Enable NVDA.
2. Reach https://en.wikipedia.org/wiki/List_of_Nvidia_graphics_processing_units
3. Scroll the page, click other buttons or other tabs.

Expected result

• Page should be able to scroll without issues.
  NVDA should be able to read what the user is hovering over.

Actual result

• Firefox Will freeze after scrolling for a bit.
  User is unable to click on anything.

Regression range
This issue also occurs in Nightly 80.0a1

Comment 1

[James Teh [:Jamie]]

I can't reproduce this here.

1. Was Firefox installed or did you run it from an extracted zip archive?
2. If it was run from a zip archive, can you still reproduce this when installed?
3. Does the browser freeze forever or does the freeze end?
4. If the freeze ends, could you please provide a profile?
5. Can you reproduce this in Nightly after setting the pref accessibility.cache.enabled to true and restarting Firefox?

Thanks.

Comment 2

[Rares Doghi, Desktop QA]

Hi James,

1. I was running it from a zip file, retested with the installed version and the issue does not occur with the installed build, but I did notice that the URLS from the page are not being read at all on hover by the NVDA on the Installed build, while on the Zip build they are still being read by NVDA even though Firefox Froze completely.

2. The Browser does not freeze forever, If I switch apps and focus on skype or something else Firefox will unfreeze after a few minutes. Here is the performance profile I captured: https://drive.google.com/file/d/1k9bOFg70QpbJxK-i9qxajLd3TJBrQYFM/view?usp=sharing unfortunately I couldnt upload it directly, I was only able to download it and reupload it into Drive, please let me know if you dont have access to it.

3. Yes the issue still occurs after setting accessibility.cache.enabled TRUE, but only from the ZIP file.

Please let me know if theres any other information I can provide.

Comment 3

[James Teh [:Jamie]]

Thanks.

(In reply to Rares Doghi from comment #2)

3. Yes the issue still occurs after setting accessibility.cache.enabled TRUE, but only from the ZIP file.

That's strange. While being installed or extracted from zip does have an impact on accessibility when the cache is disabled, it should make no difference when the cache is enabled. Was Firefox definitely restarted after the pref was set to true? If so, it might be useful to get a profile of the issue with the cache enabled with a zip copy too.

Comment 4

[Rares Doghi, Desktop QA]

Here is the Performance profile for zipped Nightly with cache enabled : https://share.firefox.dev/3TjDP7w

It does freeze in the beginning but it recovers a lot faster than with it disabled, but after it recovers it keeps stopping for a second or so while scrolling, its not as smooth as it is with the Installed version.

Let me know if I can help with anything else.

Comment 5

[Daniel Bodea [:danibodea]]

I've found a curious behavior with a similar test page and steps:

1. Install build (so that Accessible Handler Used is TRUE)
2. Launch NVDA (and update to 2022.4)
3. Launch Firefox (with a new profile, CTW is off in beta and release).
4. Load https://en.wikipedia.org/wiki/World_War_I and scroll the page to observe when it becomes responsive.

Exected: The browser does not freeze and it does not show performance issues. NVDA reads the page.

Actual: The browser freezes for as long as a minute and then, it also shows performance issues for a few seconds.

The curious part is that Beta MSIX build shows a longer freeze and UI stutter until it behaves as expected:

• Beta v110.0b8 MSIX: a ~1-minute freeze and ~30-second UI stutter while scrolling the page.
  (Performance Profile: https://share.firefox.dev/3DyRTE9 )
• Beta v110.0b8 exe install: a ~15-second freeze and ~20-second UI stutter while scrolling the page.
  (Performance Profile: https://share.firefox.dev/3WTptM8 )
• also, there's no significant difference between the behaviors of the Release MSIX and Release exe install:
  both have a ~15-second freeze and ~20-second UI stutter while scrolling the page.

• This was tested in Windows 10.

Jamie, should I log a new bug with this?

Comment 6

[James Teh [:Jamie]]

It does seem very odd that the behaviour is different between these builds. Using the profile, I verified that the beta MSIX build is definitely using the accessible handler code as it should.

We're pretty close (next few months) to shipping CTW now, so I don't think it's worth putting time into figuring this out. However, I'm leaving this open to investigate the differences between different builds with CTW enabled once CTW ships. We should include the MSIX build in any testing we do there.

One possibility is that this is somehow related to timing or cache (not a11y cache). I know that loading fonts (which happens soon after startup) can cause the browser to reflow all documents, which can have a significant impact on a11y performance. See bug 1770606 comment 25 for details.

Comment 7

[James Teh [:Jamie]]

Daniel, are you still able to reproduce the difference between different builds in Firefox 113 and above? Note that accessibility.cache.enabled is true by default now. There's no need to test with it disabled.

Comment 8

[Daniel Bodea [:danibodea]]

I have just retested this issue on Win10 with Beta v114.0.b7 MSIX installation and .exe installation; This issue is almost entirely gone considering the browser still shows low performance for about 5 seconds or less. Compared to 1-2 minutes of freeze and low performance that can be observed if CacheTheWorld is disabled, the issue is barely comparable.

In conclusion, there is no noticeable difference between the MSIX and .exe installations with the steps in comment 5.

Comment 9

[James Teh [:Jamie]]

Okay. It'd be good if we could improve the performance here, but it's no longer a freeze as it was originally.

Comment 10

[James Teh [:Jamie]]

Downgrading to s3 as per comment 9.

Comment 11

[James Teh [:Jamie]]

Profile from current Nightly: https://share.firefox.dev/4e7fDz5

Comment 12

[James Teh [:Jamie]]

Because it looks like we're spending a bit of time in hash table functions, I tried refactoring AccAttributes to use an array. Profile: https://share.firefox.dev/3X9iG30
This doesn't make much of a difference, suggesting that it's the massive number of lookups rather than the hash table being a bottleneck.
For reference, some local debugging and testing with Wikipedia, Searchfox, Google Search and a few other sites showed that the maximum number of keys in AccAttributes in the parent process is 14, which is why I thought this might be worth a shot.

Comment 13

[James Teh [:Jamie]]

Given that there is no clear bottleneck here, this is not a significant problem and we don't have a reliable way to measure whether we're improving things here, I'm removing this from the 24h2 project.