1747612 - Firefox freezes when used with a screen reader and the first opened page is a page of a GitHub user

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Łukasz Golonka]

STR:

1. Start a screen reader (tested with both NVDA and JAWS versions 2018 and 2021).
2. Open Firefox and go to https://github.com/lukaszgo1
3. If the problem does not reproduce close Firefox and repeat step 2.

What happens:

90% of the time Firefox freezes meaning you cannot interact with its window in any way. According to a sighted person the web page is displayed normally though you cannot click or scroll anything. If you try to alt + tab to a different application and then back to Firefox its window is no longer visible.

What should happen:

The web page should load all the time and I should be able to interact with it.

Additional info:

Some additional findings which may be helpful are:

• This is not specific to my Firefox profile or even my user account (tested with a clean Windows user profile, and by extension clean FF config).
• This does not occur without a screen reader running (I've tested this by opening a URL mentioned above several times blindly and then ensured that the text of the web page can be selected and copied which cannot be done when the page fails to load).
• This does not occur when a different page is loaded before attempting to open GitHub for example if I'll open amazon and then go to the GitHub profile it loads correctly all the time.
• I've tried running NVDA's COM registration fixing tool but it didn't fix this issue.

Since Firefox just freezes rather than crashes (which means there is no crash report I can link to) and this seems to be unique to my machine if there are any additional things you want me to try I'd be very happy to provide whatever info is needed to help with fixing this problem.

Comment 1

[Andrei Purice]

Hey Lukas,
I tried reproducing this issue on the latest versions of Firefox Nightly 97.0a1 (2021-12-28), beta 96.0b9 and release 95.0.2 but it works for me. Tried on Windows 7 with NVDA and followed your steps but didn't get the freeze.

Can you test the issue while in Safe Mode? You can find helpful info here : https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode .
Also a fresh new profile could help. You can find more about creating a new profile here : https://support.mozilla.org/en-US/kb/troubleshoot-and-diagnose-firefox-problems#w_6-create-a-new-firefox-profile .
If possible, you can test this issue on the nightly build as well. Download the build from : https://www.mozilla.org/en-US/firefox/nightly/all/ .

Comment 2

[Łukasz Golonka]

(In reply to Andrei Purice from comment #1)

Can you test the issue while in Safe Mode? You can find helpful info here : https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode .

Still reproducible

Also a fresh new profile could help. You can find more about creating a new profile here : https://support.mozilla.org/en-US/kb/troubleshoot-and-diagnose-firefox-problems#w_6-create-a-new-firefox-profile .

As mentioned in the bug description I've tried with a clean profile and it made no difference i.e. I still get the freeze.

If possible, you can test this issue on the nightly build as well. Download the build from : https://www.mozilla.org/en-US/firefox/nightly/all/ .

I'm using Nightly as my daily browser and the freeze is reproducible with it.

I've also tried on a Windows 7 vm and I cannot reproduce the freeze there, so as mentioned in the bug description, there is something particular to my system which causes the freeze to occur.

Comment 3

[James Teh [:Jamie]]

I was unable to reproduce this despite multiple restarts and profiles. Unfortunately, the only way to debug this is to get a stack dump using a debugger like WinDBG, but WinDBG is pretty difficult to use and is not something I can reasonably teach here. It's also particularly difficult to use with a screen reader because debugging a process freezes the process and often takes the screen reader with it.

One question: if you go to about:support, what do you see below "Accessible handler used": true or false?

If you're willing, I'd also be interested to know what happens if you try our new caching architecture. You should be aware that this is highly experimental and very incomplete, so a lot of stuff won't work properly with it enabled. You absolutely should not run with this turned on for any serious usage. Nevertheless, if you want to try (I'd recommend a fresh test profile), you can go to about:config, search for accessibility.cache.enabled and toggle it to true, then restart Firefox. To turn it off again, set that preference to false in about:config and then restart Firefox.

Comment 4

[Łukasz Golonka]

(In reply to James Teh [:Jamie] from comment #3)

Unfortunately, the only way to debug this is to get a stack dump using a debugger like WinDBG, but WinDBG is pretty difficult to use and is not something I can reasonably teach here. It's also particularly difficult to use with a screen reader because debugging a process freezes the process and often takes the screen reader with it.

Would it be possible to generate a dump from the frozen Firefox process using task manager and then send it for debugging?

One question: if you go to about:support, what do you see below "Accessible handler used": true or false?

True

If you're willing, I'd also be interested to know what happens if you try our new caching architecture.

It seems this does the trick - with the new caching stuff enabled the GitHub page loads each time without Firefox freezing.

Comment 5

[James Teh [:Jamie]]

(In reply to Łukasz Golonka from comment #4)

Would it be possible to generate a dump from the frozen Firefox process using task manager and then send it for debugging?

The dumps generated by Task Manager are full memory dumps, so they are huge (potentially hundreds of mb). You could try using procdump which is a command line utility. You could just do procdump pid, where pid is the process id. The challenge here is that there are multiple Firefox processes and procdump will only handle one process at a time. Given that this works with the cache enabled, I suspect this is a deadlock, so we'll need dumps from the relevant Firefox content process as well as the main process... and because it's frozen, there's no easy way of knowing which content process to dump! That means you'll need to dump all of them, which is pretty painful.

I totally understand if this tedium isn't worth the effort for you. If you do decide to go down this path, please email me the dumps privately, as they may contain sensitive information and shouldn't be attached to a public bug.

It seems this does the trick - with the new caching stuff enabled the GitHub page loads each time without Firefox freezing.

The good news is that this caching architecture will eventually be the default. One of the reasons we're working on it is precisely because it makes obscure bugs like this far less likely. The bad news is that we're many months away from this being ready for wider testing, let alone shipping. That makes it difficult to determine whether it's worth trying to track this down given the tedium involved in doing that.

If you can live with this issue for now, it might be worth just waiting until the caching work is done. If it causes you regular trouble, I'll certainly look into it, but I'll need the dumps for all processes as described above in order to have a chance of making any progress... and there's still no guarantee I'll be able to figure it out without being able to reproduce it myself.

Either way, sorry this is causing you trouble.

Triage note: This is a pretty severe issue when it occurs, but I'm marking as s3 because it appears to be limited to a very specific scenario on a single system.

Comment 6

[James Teh [:Jamie]]

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