Open Bug 1472530 Opened 6 years ago Updated 2 years ago

Severe performance regression in Firefox while Windows speech recognition is running due to multi-process

Categories

(Core :: Disability Access APIs, defect, P3)

Product:
Core
Component:
Disability Access APIs
Platform:
Unspecified
Windows
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 --- affected
firefox61 --- affected
firefox62 --- affected
firefox63 --- affected

People

(Reporter: philipp, Unassigned)

References

(Blocks 2 open bugs)

Details

a user on reddit reported that windows speech recognition is making firefox unbearably slow as soon as it's run and that preventing accessibility services from accessing the browser through the preferences would solve the matter: https://old.reddit.com/r/firefox/comments/8uzpir/windows_speech_recognition_destroys_firefox_any/ this issue was easily reproducible on windows 10 when launching the speech recognition tool from the legacy windows control panel and making sure that it's actively listening for voice input - page operations become immediately very slow. it's showing up in about:support like this: >Accessibility >Activated true >Prevent Accessibility 0 >Accessible Handler Used false >Accessibility Instantiator UNKNOWN|C:\Windows\Speech\Common\sapisvr.exe i took a perf profile from the affected state (switched on speech recognition, navigated to reddit and tried scrolling down on the page, then opening the menu and going to the about firefox dialog): https://perfht.ml/2tY8I78
(In reply to [:philipp] from comment #0) > >Accessible Handler Used false Was this an installed build or a build copied from somewhere/manually extracted from a zip archive? Installed builds should always report true for accessible handler used. If this is false (e.g. because the build isn't installed), there will certainly be performance problems, as the caching code we use to optimise accessibility calls across processes isn't running. The need to "install" this is an unfortunate limitation imposed on us by Windows COM. The question is whether users experiencing this are all running builds which aren't installed, or whether it's also experienced with builds that *are* installed. The former is IMO not a "normal" configuration. The latter is definitely a concern. Did the user reporting this suggest that this was new in Firefox 61 (or provide any other info concerning versions)?
Flags: needinfo?(madperson)
Priority: -- → P1
yeah sorry, i was mainly testing different versions in portable firefox. the issue is present as well in a fixed installation though (and Accessible Handler Used is shown as true then). it's not a new problem in firefox 61 as far as i could see. 52esr appeared to be a lot more responsive though, so i think it may just be a general fallout from enabling e10s with a11y.
Flags: needinfo?(madperson)
Moving to p3 because no activity for at least 24 weeks. See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Priority: P1 → P3

I am experiencing this issue on an installed version of Firefox Quantum 65.0.2 in Windows 10. When Windows Speech Recognition is running, Firefox becomes totally non-responsive. To make matters worse, the speech recognition will only work for a very short amount of time and then will no longer recognize anything that I say. Only way to get it to work is to restart the speech app which only works for a short bit again or to shutdown Firefox which eliminates the problem completely.

I have developed arthritis in my fingers so I really need this working! Unfortunately with my job, I need to have Firefox open all day and I really don't want to switch browsers.

I am more than willing to provide more info or beta test should that help to speed things along.

I just read 1418290 and found out about the accessibility setting. I tried enabling it to block Windows Speech Recognition from accessing Firefox. It had the intended effect of not killing Firefox's performance.

However as far as the speech recognition, it had the opposite effect. Instead of working for a very short time, it now wouldn't work at all (kept displaying "What was that?") as long as Firefox was running. Shutdown firefox and it suddenly starts working again. So I am back to no workaround short of ditching Firefox. :(

I have put the accessibility setting back to default and managed to slowly get the following info for you.

Activated true
Prevent Accessibility 0
Accessible Handler Used true
Accessibility Instantiator UNKNOWN|C:\Windows\Speech\Common\sapisvr.exe

New perf profile: https://perfht.ml/2HlgLTv
It looks like there is a UIA bulk fetch going on, but I don't know what WSR is looking for.

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

New perf profile: https://perfht.ml/2HlgLTv
It looks like there is a UIA bulk fetch going on, but I don't know what WSR is looking for.

With WSR, you can use your voice to click on screen elements by name. So perhaps it is collecting a list of all user interface elements ahead of time.

Thank for you quick response James Teh.

Today I learned that Windows Speech Recognition must be loaded before the app that you want to control. WSR is now working fine whether Firefox is running or not as long as I start it before Firefox. However Firefox is still unresponsive and basically useless, but at least I can and make use of the Speech Recognition and just put it to sleep it when I need to use Firefox.

This appears to be a duplicate of a 10-year-old bug here that is still unresolved:
https://bugzilla.mozilla.org/show_bug.cgi?id=732872

Thanks. I'm keeping this open rather than marking it as a dup because this bug is more specifically related to the severe performance regression after Firefox 57; i.e. after Firefox switched to multiple processes. In contrast, the original bug 732872 is more generic and covers performance issues from before multi-process happened.

Blocks: 732872
Summary: Severe performance regression in Firefox while Windows speech recognition is running → Severe performance regression in Firefox while Windows speech recognition is running due to multi-process
Depends on: a11y-ctw
Depends on: 1737192
No longer depends on: a11y-ctw
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.