Single-Key Navigation does not work with FireFox

[TamerSoliman]

Steps to reproduce:

1. Install NVDA 19.3.1 or 19.2.1 on Windows 10 19.9
2. Install FireFox 68.7.0ESR or 75.0
3. Double click Firefox desktop icon
4. Type 'hello' and hit the enter key.
5. press the 'h' keyboard key or 'u' keyboard key to navigate to, respectively, the next heading or next unvisited link on the search results.

Actual behavior:

NVDA says 'h' or 'u' and an either an 'h' or 'u' is typed into the search box (i.e., turning 'hello' into either 'helloH' or 'helloU'.

Expected behavior:

NVDA should jump and read the next heading or next unvisited link, as is typical with single-key navigation in the browse mode.

System configuration

NVDA installed/portable/running from source:

Always installed.

NVDA version:

The problem shows up in 19.3.1; 19.2.1; and even 2020.1Beta

Windows version:

Windows 10 64 bit version 19.9

Name and version of other software in use when reproducing the issue:

The problem shos up with all permutations of the above 3 NVDA versions and the following 2 versions of Firefox: 68.7 ESR and 75.0 standard.

Other information about your system:

1. pressing 'insert' + 'spacebar' to manually activate the browse mode doesn't help.
2. Navigating by the 'down errow' results in NVDA announcing 'headers' and 'links'; so it is not a recognition problem.
3. Chrome and Opera show the same problem (I don't use these anyway).
4. With Windows Edge: navigating by 'h' to next header or 'e' to next edit box or by 'k' to next linkk work, but navigating to visited or unvisited links returns 'unimplmented'unimplemented in this document'.
   So, not sure if it is the same problem showing in part or if it is a totally different problem.
5. Deleting NVDA's and Firefox's folders in %appdata% and reinstalling the 2 apps doesn't solve the problem.

Other questions

Does the issue still occur after restarting your computer?

Yes, and it even persists after re-installing the windows OS from scratch!

Have you tried any other versions of NVDA? If so, please report their behaviors.

See above

If addons are disabled, is your problem still occuring?

Yes.

Did you try to run the COM registry fixing tool in NVDA menu / tools?

Yes, and it didn't fix the problem.

[josephsl]

Hi, which page is this? In order to use first letter navigation commands, one must be in browse mode ,and based on description, NVDA isn’t switching to it somehow. Thanks.

[feerrenrut]

@TamerSoliman When you attempt to switch to browse mode with insert+space, do you hear a "boop" or "browse mode" announced?

It would be helpful to get an NVDA log, perhaps there is some clue to explain what is happening. Please ensure that this is at debug level (set on the general settings panel). If you aren't sure, please see the wiki page for how to collect the log.

[Adriani90]

@TamerSoliman does the navigation with tab and shift+tab work properly with NVDA in Firefox?
Do you have by chance installed and uninstalled Skype for business on that machine?
It might be related to #7778 which sugerates that Skype for business might unrergister COM DLLs which are not included in the COM registration fixing tool.

[TamerSoliman]

nvda.log
@josephsl and @feerrenrut Yes, I get the expected sound indicator when I press insert+space, but 1-key navigation doesn't work afterwards. A log is attached where I try to navigate using the following single keys: h, u, k, l, and i.
@Adriani90 Navigation through tab and shift+tab works as expected in Firefox. I haven't installed Skype for Biz on this machine.
p.s. 1-key navigation works as expected on the desktop.
Thanks guys!

[feerrenrut]

Thanks for the log. The following is quite technical, and may not be very helpful to you immediately, but is intended as notes for anyone investigating this further.

My hunch is that this is due to the freeze.

IO - speech.speak (08:40:48.242) - MainThread (11284):
Speaking [<speech.commands.CallbackCommand object at 0x082ECA30>, LangChangeCommand ('en_US'), 'form', 'link', 'graphic', LangChangeCommand ('en'), 'Stay Home. ']
DEBUGWARNING - watchdog._watcher (08:40:56.695) - watchdog (12052):
Trying to recover from freeze, core stack:
  File "nvda.pyw", line 215, in <module>
  File "core.pyc", line 545, in main
  File "wx\core.pyc", line 2134, in MainLoop
  File "gui\__init__.pyc", line 1030, in Notify
  File "core.pyc", line 514, in run
  File "IAccessibleHandler.pyc", line 898, in pumpAll
  File "IAccessibleHandler.pyc", line 772, in processForegroundWinEvent
  File "IAccessibleHandler.pyc", line 531, in winEventToNVDAEvent
  File "_UIAHandler.pyc", line 556, in isUIAWindow
  File "_UIAHandler.pyc", line 534, in _isUIAWindowHelper

DEBUGWARNING - NVDAObjects.IAccessible.IAccessible._get_IAccessibleRole (08:40:56.735) - MainThread (11284):

After this we don't get any executeGesture logging for the keys pressed. I assume the announced u h k l was due to key presses. This makes me think that NVDA is not getting the key press events for for Firefox.

We'd need to do some much deeper investigation to confirm, but my hunch is they keyboard hook gets silently removed:

The value is in milliseconds. If the hook procedure times out, the system passes the message to the next hook. However, on Windows 7 and later, the hook is silently removed without being called. There is no way for the application to know whether the hook is removed.

See Remarks section of MSDN for LowLevelKeyboardProc

If that is the case, the value for the timeout can be altered in the Windows registry:

The hook procedure should process a message in less time than the data entry specified in the LowLevelHooksTimeout value in the following registry key:

HKEY_CURRENT_USER\Control Panel\Desktop

The value is in milliseconds.

On my machine the value for this is 5000, so 5 seconds. I noticed that the timestamp in the log before the watchdog entry is (08:40:56.695 - 08:40:48.242) about 8 seconds before.

[lukaszgo1]

The fact that NVDA can freeze inside _isUIAWindowHelper worries me as this method is quite simple IMHO. Perhaps adding additional logging to this method when UIA is checked in the debug log categories would be helpful to track similar issues?

[feerrenrut]

In NVDA 2019.3.1 Line 534 of _UIAHandler was res=windll.UIAutomationCore.UiaHasServerSideProvider(hwnd) I don't think we have any use for UIA in Firefox, perhaps this could exit early based on an appmodule or similar.

Probably worth asking @jcsteh for his advice here.

[TamerSoliman]

@feerrenrut The following doesn't solve the problem:
control+insert+z

python
import config
config.conf['UIA']['enabled']=False
exit()

ult+control+n

[jcsteh]

While it's true that Firefox doesn't need UIA at this stage, my suspicion (as seemingly confirmed by later comments) is that the breakage here is symptomatic of another problem, rather than the problem itself. I've heard of a few rare cases of users experiencing this. I'm slightly concerned there might be some other application on the system which is hooking typed characters, but I don't really know how to prove that.

[Adriani90]

@TamerSoliman could you post a list of the programs installed on your PC to see if something might be related there?

[TamerSoliman]

The problem was resolved incidentally when I setup the demo version of JAWS2020 on the machine -:)

[Adriani90]

Thanks for reporting. I guess there was something wrong with your graphic card settings. Jaws automatically adjust graphic card settings to be optimal for screen readers. If you are having this issue again, consider to re-install your graphic driver.
I am closing as works for me.