Firefox 57 and Later Unusable with NVDA

[elliott94]

When using the latest NVDA snapshot (next-14617,ef52ddc4) in combination with Windows 10 (10.0.15063 Build 15063) and the latest version of Firefox (57 X64), NVDA is literally unusable and results in the word "unknown" being output whenever I tab around the window. Reading the content of editable fields (including the Address Bar) works without issue, but all other interaction results in the behaviour outlined above. I've ensured that the "Prevent accessibility services from accessing your browser" checkbox is unchecked; when this is ticked, nothing at all reads so I can definitely tell that this is not the issue. I'm aware that huge changes have been made to the internal functionality of the latest release, but it was hinted that this would only cause slowness and not complete degredation of the browsing experience. When testing with several different Windows 7 configurations, whilst there are some issues that need to be addressed by Mozilla separately I am successfully able to navigate around web pages as expected. Testing with both Firefox 57 X86 and X64 on the same machine gives me the same result. I wanted to see if anybody has experienced anything similar or if Mozilla are aware of this.

[Brian1Gaff]

Yes I get this on Windows 7 even with the current release candidate, but from what I read this is actually a known issue. I'm not sure why only some machines get this effect so maybe some more research needs to be done. Of course if the machine is slow it will take a bit of time to allow firefox to catch up. That is not the issue on my machine though, but single and double core systems running 7 and 10 could be affected. Best course is ff 52esr as mentioned elsewhere. I did suggest that a warning be put on the nvda start page, but everyone else assumed people would know about it. I'm saying no more! bglists@blueyonder.co.uk Sent via blueyonder. Please address personal email to:- briang1@blueyonder.co.uk, putting 'Brian Gaff' in the display name field.

[feerrenrut]

I haven't been able to reproduce this in Windows 10 with a recent next build of NVDA and Firefox 57.0 (64-bit) and 57.0.1 (64-bit). If anyone can reproduce this, I would be interested to see a log, and the NVDA developer info.

[jcsteh]

@elliott94, could you please try these instructions (adapted from those I posted in #2807 (comment)):

1. Please apply this registry patch (remove the .txt extension).
2. Please also apply this second registry patch (remove the .txt extension).
3. Open a command prompt as administrator: Start menu, type cmd.exe into the search box, press control+shift+enter and accept the UAC prompt.
4. Enter the following commands:

   c:\windows\system32\regsvr32 c:\windows\system32\oleaut32.dll
   c:\windows\system32\regsvr32 c:\windows\system32\actxprxy.dll
   

5. Also enter the following commands:

   c:\windows\syswow64\regsvr32 c:\windows\syswow64\oleaut32.dll
   c:\windows\syswow64\regsvr32 c:\windows\syswow64\actxprxy.dll
   

6. Also enter the following command:

   c:\windows\system32\regsvr32 c:\windows\system32\OneCoreCommonProxyStub.dll
   

7. Also enter the following command:

   c:\windows\syswow64\regsvr32 c:\windows\syswow64\OneCoreCommonProxyStub.dll
   

Does that resolve the issue?

[elliott94]

@jcsteh - Thanks for these. However, I already had to previously apply this fix to resolve an issue related to an installation of the Skype for Business client... so this time, it's unfortunately not the issue! I'll do some more investigation and post updates as soon as I have any.

[jcsteh]

I recall that, though I thought that was on a different machine (Windows 7). That said, it's also possible that something installed after that point broke something, even if the results aren't quite as nasty. It'd be great if you could apply the instructions again just in case. Failing that, this suggests there's another dll or registration we're missing. If that's the case, is there any chance at all I might be able to remote in at some point and take a look?

[mrazzari]

I have the same issue. Windows 10 Home 64 bits, version 1607. Firefox 57.0.2 64 bits.
"Prevent accessibility services" is not checked.

Tested both NVDA 2017.4 and NVDA next 14728 (from Dec 12).

Tried the steps above.

The "OneCore" ones result in an "DllRegistryServer entry point not found" error.

Firefox ESR works fine.

Is there any further info I can provide to help debug this?

[bleeblat]

I have the same issue on windows 10 64-bit with firefox 58. Same errors and things as the previous comment. I think one of the windows updates broke something as it worked once before, then stopped working. I tried to register the DLL's again and applied the registry patches according to the directions. The firefox window reads fine except for the web page. But it's weird, because pages that begin with about: like about:support for example, will read the content fine, but www.google.com will not read the content at all. It just says unknown. But the rest of the windows in firefox like menus and context menus and dialogues and all that, read as one would expect. What sort of information can I send to help this out? You could remote in as well if you'd like, if that helps. Ordinarily I wouldn't mind because I have chrome as the default browser, but some pages render or read weirdly in Chrome. So I'd rather use Firefox as the default browser, mostly for things like reader mode and better usability of some form fields.

[Brian1Gaff]

Hi if you go back to the version 52esr are the problems cured or still there? Brian

[comanna]

Quentin, I am using Firefox 59.0 64 bit in Windows 10 with latest NVDA. When I use Firefox, I cannot open some links. If you try the web site www.brayarts.net <http://www.brayarts.net> you will find that Firefox opens the links to the associated pages on the web site but not to the attached .PDF files. For example, open “Brochures Page”. When this page opens you will see that it is laid out in sets of HTML tables containing a link to a .pdf brochure in each cell of the table. The brochure files are held on the website. When I press tab to get to any of these links, NVDA echoes that I am on the link and numpad 5 confirms this. I press space bar to open it. This has always worked up to last month but Now, all that happens is that Firefox opens a new tab with nothing in it! I tried using JAWS to see if this was a problem for NVDA alone but JAWS was also unable to open the link so, I think it is a Firefox problem. Does NVDA have another means of opening a link besides the space bar, the application key, numpad * or numpad enter, … All of these do nothing! Would you try the link www.brayarts.net <http://www.brayarts.net> and see if you are having the same trouble?

[jcsteh]

Can anyone still reproduce this?

Note that the system registry fixes above now get applied by NVDA when it is installed. You can also re-apply them by using NVDA menu -> Tools -> Run COM Registration Fixing tool. So, all you need to do is install a recent version of NVDA (2018.2 or later) and test again.

[jcsteh]

@comanna commented on Apr 25, 2018, 2:53 AM GMT+10:

When I use Firefox, I cannot open some links.

That's a different issue from the one reported in this issue. Please file a new issue with information specific to that problem. Thanks!

[elliott94]

Unfortunately, yes - this is still an issue for me on this one same machine. Firefox 56.0.2 is the last version that works without issue - definitely not related to the fixes outlined above; other apps work without issue, and applying these from within NVDA unfortunately doesn't resolve.

[jcsteh]

Okay. So we're obviously missing one more COM registry problem, but I have no idea what it could be yet. <sigh> I'll think some more. Just to clarify, was Firefox installed with the official installer/updater?

[elliott94]

It was. So, just to confirm the process:

1. Firefox was updated automatically, at which time I realised that accessibility was broken.

2. I completely removed both the Firefox application and Mozilla Service, restarted, and removed everything from the following directories:

C:\Program Files\Mozilla Firefox

C:\Users\Username\AppData\Local\Mozilla

C:\Users\Username\AppData\LocalLow\Mozilla

C:\Users\Username\AppData\Roaming\Mozilla

3. Downloaded a copy of the full Firefox installer (from https://download.mozilla.org/?product=firefox-latest-ssl&os=win64&lang=en-US), installed but noticed the same result.

4. Tried a version of the latest copy of the browser packaged by PortableApps (https://portableapps.com/apps/internet/firefox_portable) (not affiliated with Mozilla) with the same results.

Sorry for such a hard one to figure out... it really is a strange one. On the off-chance, I also use Skype for Business 2016 on this machine which is known for causing COM errors - the installer that I use can be found here if it helps replicate the issue at all:

https://download.microsoft.com/download/8/7/E/87E24B50-9C85-4B1D-A581-94AA037803F8/lyncentry_4417-1000_x64_en-us.exe

[Adriani90]

I guess this issue is not only related to firefox, see #8389 and comments.

[elliott94]

Just updating this on the off chance that anybody has new ideas on what could be causing this. My main concern is that in corporate environments where NVDA is being used and where keeping software updated is key, the inability to use latest versions of the browser could start to be a big problem. Browser support for Firefox is without a doubt the best browser/screen reader combination, but obviously security is also hugely important to consider.

[jscholes]

So this still occurs with the latest versions of Firefox? In #7778 (comment), you hinted that the Skype for Business installer might have something to do with it. Would it be at all possible for you to test your theory, maybe by creating a Windows 10 virtual machine? I don't think anybody would argue with the fact that Firefox being completely inaccessible on some machines is a big problem.

[elliott94]

The SFB installer was mentioned because this is a perfect example of an executable that completely breaks accessibility when installed; however, the COM registration fixes tool included with NVDA fixes this.

Unfortunately, I don't have any free hardware that I can load any virtualisation software onto at the current time - I can, however, test on the laptop with the problem if required. Sorry for the trouble.

[Adriani90]

@elliott94 so the issue is solved for you by the com registration fixing tool?

[elliott94]

Sorry. Running the COM tool fixes the problems I have with Skype - however, it unfortunately doesn't with Firefox. I am still experiencing the exact same issue.

[Adriani90]

I had the same issue on Firefox and talked with Jamie on Gitter about this. Unfortunately it is not possible to investigate it. It could be something stored in cash which prevents com registry dlls to work correctly. But in is almost impossible to find which com registry dll could be. I will let this issue open maybe someone can find a solution. In my case it only helped to reset my system to factory default. I tried every kind of fixing tools I could find and tried to register many com registry dlls manually but it didn't help.

[elliott94]

Just a small update.

After testing this on a separate machine with a freshly-installed build of Windows 10 (the same version as initially outlined in my description for this ticket), I am experiencing the exact same behaviour. It definitely seems like something is up with the corporate build that my organisation are using; that to one side, however, this is definitely caused by a change between Firefox 56.0.2 and 57; NVDA is able to interact with content in 56 without issue, but as soon as 57 is opened the problems start.

[jcsteh]

Firefox 57 and later use some facilities of COM that weren't used by earlier versions. However, under normal circumstances, there's no reason this should be a problem. The question is what is being changed or installed by your organisation which causes this. I haven't yet been able to figure that out, as I haven't been able to reproduce it here or access a machine which manifests this.

[elliott94]

So! An update - hopefully we're getting there. I tested the following on a clean installation of Windows 10 1803:

1. Installed a fresh copy of Firefox 67.0.1 - everything is good at this point

2. Installed the Skype for Business 2016 client - at this point, accessibility breaks

3. Try to repair things - both by using the built-in NVDA COM registration fixing tool, and by following the instructions outlined in Skype for Business 2016: Installation causes Degredation of Output with NVDA on Windows 7 #7311 - things are still broken

4. Uninstalled the Skype for Business 2016 client, and re-ran the above instructions - things started working again!

So, I can now be 100% sure that the SFB client is the issue. Does anybody have any ideas as to how I can directly speak to Microsoft to let them know about this? Skype is essential as part of my job, but keeping up with Firefox security updates is also important!

Thanks.

[Adriani90]

cc: @michaelDCurran

[elliott94]

So - a small update.

I've now had chance to test this in a slightly different setup with Windows 7 rather than 10. If installing NVDA 2019.2.1 onto a machine running Windows 7 X86 and then install the Skype for Business 2016 client, everything in Firefox continues to read as it should - however, if I then perform the exact same steps on the same machine after it has been imaged with Windows 7 X64, the above breakage can be observed. I'm now wondering whether the build of Firefox that's being run (either X86 or X64) could have anything to do with this - but it definitely appears to be related to the machine architecture in this case.

[Adriani90]

@elliott94 do you still see this issue with NVDA 2020 Beta or 2019.3.1 and Firefox 75?

[elliott94]

Yes - this is still reproduceable with both the latest versions of NVDA and Firefox on Windows 7 X64.

[zahra21]

i read this issue and paid attention to it especially when i commented on the issue 7269
i wish to ask the users which antivirus or antimalware programs do you use?
i think that maybe some security softwares prevent nvda from accessing firefox because of their false positive problem.
i completely trust nvda, but for example: i remember that i read that avast antivirus recognizes libreoffice as a trojan and its maybe true for nvda.
i tested with nvda 2017.3 and nvda 2017.2 with firefox before quantum on both windows xp and windows seven and all versions have excellent support with nvda.
in firefox quantum, i remember that in 2018, i tested firefox portable 61.0.1 with nvda 2017.2 and the result was only crashing of firefox even in simple web pages like gmail in basic html view
and user guide and what's new in nvda files.
i should say that i dont trust and never dont use any antivirus, antimalware,and other security programs except windows firewall.
but i remember that in 2014 or 2015, i tested one antispyware program which is called WinPatrol,
and i even could not navigate simple web pages.
the result was overheating my laptop and unresponsiveness of nvda and firefox or one of them.
i did not say exactly which one because my system became unusable for me before removing that program.

[elliott94]

That's an interesting thought; multiple anti-virus products were in use at the time of my testing this issue since reporting this 3 years ago. That said, it definitely appears that the Skype for Business 2016 installer has something to do with this - rather than any particular anti-virus product specifically.

[Adriani90]

@elliott94 is this issue still reproducible for you? Now that #12560 has been merged things should be much better. Also note that #12355 is still in work and will probably fix also further cases.
cc: @XLTechie

[XLTechie]

I agree that #12560 might have helped with this. But #12355 concentrates on UX, and is unlikely to have any effect. If this can still be reproduced, I would like to see copies of the registry both before (while things are working) and after (while their not). The regshot tool can do this. https://sourceforge.net/projects/regshot/ Of course, I would not advise posting copies of registries here given what they might contain. You can send them to me privately if you wish. Better yet, if you want to do the registry diffing yourself, and post the differences here, that might lead to a solution.

[jcsteh]

The recent accessibility re-architecture in Firefox 113 eliminates the obscure COM usage that caused this problem to manifest in Firefox 57+ on systems with broken registry entries. It's still possible for even more broken registry entries to break web browsers, but the breakage would now be across all browsers, rather than only web content in Firefox. Thus, I'm closing this issue.