Disabling multiprocessing seems to workaround FF 57's slowness with NVDA screen reader - Are there potential problems with doing so?
There's a lot I like about the new Firefox 57 (Quantum). Generally, it is faster than FF 56.0.2.
However, within the Accessibility community, it's been well reported that FF 57 is actually slower than FF 56.0.2 when using a screen reader such as NVDA or JAWS. [See http://intopia.digital/articles/screen-reader-users-told-not-upgrade-firefox-quantum, https://www.marcozehe.de/2017/11/07/firefox-57-nvda-users-perspective/, https://www.nvaccess.org/post/in-process-halloween-2017-edition/, and https://twitter.com/accessiblestef/status/925386526896328713.]
In some cases, it is much slower. It's been reported to take 13 seconds to load Wikipedia's World War 1 article in NVDA, and "close to a minute" in JAWS. I'm a freelance software tester who has recently starting helping to conduct Web Accessibility audits. Earlier this week, a client's Web site was virtually unusable with FF 57 + NVDA.
Since I'd read that FF 57's multiprocessing had something to do with the slowness, I thought I'd see if disabling its multiprocessing helped with the slowness. So, after asking how to do that on the forum, I set all my about:config entries which match "browser.tabs.remote.autostart" to false. [browser.tabs.remote.autostart was already false, but browser.tabs.remote.autostart2 was true.]
This seems to noticeably speed things up for me, but I didn't know if it might cause problems I'm not aware of. Are there potential problems with doing so? Or does this seem like it might be a good workaround for using Firefox 57 with NVDA (and possibly JAWS as well)?
Does anyone else find that doing this speeds up their usage of FF 57 with NVDA, JAWS, or any other screen reader?
Thank you.
ప్రత్యుత్తరాలన్నీ (3)
No there is no issue in doing this. As well this is the Answer for this and other issues in that version. Go to the Firefox 3 Bar Menu --> Help ? --> Troubleshooting Information Page and take a look in the Accessibility section if accessibility is set to "true" there. if yes, go to the Firefox 3 Bar Menu --> Options --> Privacy & Security panel and under Permissions check the setting to Prevent Accessibility Services from accessing your browser. Restart Firefox
" I set all my about:config entries which match "browser.tabs.remote.autostart" to false. [browser.tabs.remote.autostart was already false, but browser.tabs.remote.autostart2 was true.] "
Do not need to do that now in 57+ can do the above and this :
You could try this please : Go the Menu then Tools --> Options --> Performance and untick everything. change the recommended size lower then see how it runs. Note: 0 = No Multi-proccesor = slow again. Hardware Acceleration might have also been a issue so turn it off. Run it later and see as you turn things back on and test it, and again. Restart Firefox after making these changes please.
This can speed things up in a variety of applications just remember you are back down to 1 core instead of multi-core and sort of defeating the purpose.
New article out today on ram usage : https://www.howtogeek.com/334594/stop-complaining-that-your-browser-uses-lots-of-ram-its-a-good-thing/
Note : 58 will bring in Multi-Thread .
- NOTE : If you get updated to version 57.0.1 this might not be need do to fix for Accessibility in it.
Please let us know if this solved your issue or if need further assistance.
న Shadow110 చే మార్చబడినది
Sorry, I didn't get to try this out with NVDA today (on Saturday), and I'll be offline tomorrow (on Sunday).
I'll try it out on Monday.
Thanks.
Thanks for your replies.
I don't think I want to Prevent Accessibility Services, though, since I need to use the NVDA screen reader, which is an Accessibility feature.
As you suggested, I tried turning off the recommended performance settings, turning off hardware acceleration, and reducing the Content Process limit to 1 (the lowest it would allow). However, none of those seemed to help with the speed of NVDA with FF 57.0.1, and some combinations actually slowed it down.
Thanks, though, for seeking to help.