NVDA performs sluggishly when navigating emails in Microsoft Outlook, especially with complex content

[gerald-hartig]

Information transferred from https://github.com/nvaccess/nvda/issues/8026

Steps to reproduce:

1. Open Microsoft Outlook
2. Open an email message (particularly one containing attachments, priority tags, or complex content like newsletters)
3. Try to navigate through the email content using:
   • Up/down arrow keys for line-by-line navigation
   • Ctrl+arrow keys for paragraph/word navigation
   • Using say-all command

Actual behavior:

• Significant delay (over 1 second) when moving between lines using arrow keys
• Slower response when emails contain images, links, or tables
• When using speech and braille simultaneously, there can be desynchronisation (braille showing previous line)
• Say-all command may take several seconds to start and have long pauses
• Issue becomes more pronounced when NVDA and/or Outlook have been running for extended periods
• Performance degradation is especially noticeable with:
  • Emails containing large attachments
  • Messages with priority tags
  • Calendar events with attachments and priority tags
  • Newsletter-type emails with complex formatting

Expected behavior:

• Smooth and responsive navigation through email content
• Immediate response when using arrow keys for line navigation
• Synchronised speech and braille output
• Quick start of say-all command without unexpected pauses

NVDA logs, crash dumps and other attachments:

Information missing - though mentioned that NVDA continuously writes information about Outlook objects to nvda_slave.log which might be contributing to the issue

System configuration

NVDA installed/portable/running from source:

Information missing

NVDA version:

Issue has been confirmed on multiple versions up to current (2024), including:

• NVDA 2022.2
• NVDA 2022.3 beta 2
• NVDA 2023.2
• NVDA alpha-28179,345154a6 (2023.2.0.28179)

Windows version:

Information missing

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

• Microsoft Outlook 2016/365
• Various versions reported including:
  • 16.0.15427.20210
  • 16.0.15601.20048
  • 16.0.16731.20170

Other information about your system:

Information missing

Other questions

Does the issue still occur after restarting your computer?

Partial improvement noted after restarting NVDA and Outlook, but issue returns over time

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

Multiple versions tested as listed above. Some improvements noted in NVDA 2023.2 but issue persists especially with complex emails

If NVDA add-ons are disabled, is your problem still occurring?

Information missing

Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?

Information missing

Additional Notes:

• Enabling UIA for Microsoft Word appears to improve performance
• Issue has been noted as a key difference compared to JAWS performance
• The problem has been consistently reported by users since 2018
• Character-by-character navigation remains responsive; the issue primarily affects line navigation

[gerald-hartig]

@Adriani90 @CyrilleB79 I've created this new issue to collect together the information on the problem into the bug report template. Can you please confirm that it's all correct and add any missing information required to triage and address the problem.

[Adriani90]

Thanks for the great merging of information, very helpful. It seems ctrl+arrow keys (navigation by paragraph) is also faster than moving line by line, almost double as fast in focus mode, or sometimes three times faster when comparing both in browse mode.

IO - inputCore.InputManager.executeGesture (00:12:46.181) - winInputHook (2868):
Input: kb(laptop):upArrow
DEBUG - editableText.EditableText._hasCaretMoved (00:12:46.230) - MainThread (8304):
Caret move detected using bookmarks. Elapsed 0 sec, retries 0
IO - inputCore.logTimeSinceInput (00:12:46.371) - MainThread (8304):
0.190 sec since input
IO - speech.speech.speak (00:12:46.371) - MainThread (8304):
Speaking ['Leer']
IO - inputCore.InputManager.executeGesture (00:12:46.430) - winInputHook (2868):
Input: kb(laptop):downArrow
DEBUG - editableText.EditableText._hasCaretMoved (00:12:46.462) - MainThread (8304):
Caret move detected using bookmarks. Elapsed 0 sec, retries 0
IO - inputCore.logTimeSinceInput (00:12:46.571) - MainThread (8304):
0.140 sec since input
IO - speech.speech.speak (00:12:46.571) - MainThread (8304):
Speaking ['Leer']
DEBUG - UIAHandler.shouldUseUIAInMSWord (00:12:46.598) - MainThread (8304):
User does not want UIA in MS Word unless necessary
IO - inputCore.InputManager.executeGesture (00:12:47.187) - winInputHook (2868):
Input: kb(laptop):control+upArrow
IO - inputCore.logTimeSinceInput (00:12:47.267) - MainThread (8304):
0.080 sec since input
IO - speech.speech.speak (00:12:47.267) - MainThread (8304):
Speaking ['Leer']
DEBUG - UIAHandler.shouldUseUIAInMSWord (00:12:47.291) - MainThread (8304):
User does not want UIA in MS Word unless necessary
IO - inputCore.InputManager.executeGesture (00:12:47.404) - winInputHook (2868):
Input: kb(laptop):control+downArrow
IO - inputCore.logTimeSinceInput (00:12:47.480) - MainThread (8304):
0.076 sec since input
IO - speech.speech.speak (00:12:47.480) - MainThread (8304):
Speaking ['Leer']

I wonder if this has anything to do with the caret movement detection using bookmarks? Navigation with arrow keys is the only navigation patern that seem to use bookmarks for detecting caret movements, at least in focus mode. In browse mode bookmarks are not used.