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

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.

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.

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.

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.

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?

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.

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.

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.

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

Downgrading to s3 as per comment 9.