nvda icon indicating copy to clipboard operation
nvda copied to clipboard

Spoken key commands are interrupted by resulting events of the key command

Open abdel792 opened this issue 2 years ago • 9 comments

Steps to reproduce:

  1. Enable Speak Command Keys
  2. Press NVDA+F1
  3. Note that NVDA announces "NVDA NVDA log viewer" - the full command key is interrupted.

Actual behavior:

The command key is interrupted

Expected behavior:

The command key is not interrupted.

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

2021.2

Windows version:

Windows 10 version 21H1.

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

Other information about your system:

Other questions

Does the issue still occur after restarting your computer?

Yes

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

I tried with the current alpha version 24170, the behavior is the same.

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

Yes

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

Yes

abdel792 avatar Nov 04 '21 06:11 abdel792

I think that the message "Hello everyone!" is spoken but the message ">>>" supplants it.

aaclause avatar Nov 04 '21 08:11 aaclause

Thanks @aaclause,

No no,

By the way, if you just type this, the behavior is the same:

import speech # Not required, speech is imported by default in NVDA's Python console.
import ui
speech.speakMessage ("Hello everyone !", priority = speech.priorities.Spri.NOW)

Or:

import ui
ui.message ("Hello everyone !", speechPriority = speech.priorities.Spri.NOW)

abdel792 avatar Nov 04 '21 09:11 abdel792

What is spoken instead @abdel792?

Please collect a debug level log while testing this and attach it to the issue, it contains the speech sequences sent to the speech manager.

feerrenrut avatar Nov 04 '21 10:11 feerrenrut

Thanks @feerrenrut,

In fact, nothing is spoken.

Here is the debug level log with the add-ons disabled.

Thanks again.

abdel792 avatar Nov 04 '21 12:11 abdel792

@feerrenrut,

Please consider the following:

The speech is also not spoken if the focus changes soon after.

If you run the following code in the console, the speech is not spoken too:

from globalCommands import commands
speech.speakMessage ("Hello everyone !", priority = speech.priorities.Spri.NOW)
commands.script_activateKeyboardSettingsDialog(None)

It would be better if priority was given to speech even if a dialog box opens right after.

Thanks again.

abdel792 avatar Nov 04 '21 12:11 abdel792

Hi @feerrenrut,

Would there not be a possibility to prevent the interruption of a message defined as priority?

This is the main concern of this issue.

Or, if the priority cannot provide this benefit, add a new parameter, "interrupt", for example, which would prevent this interrupt ?

Thanks again.

abdel792 avatar Nov 05 '21 17:11 abdel792

They way this is being run in the python console is not very representative of how speech works generally. Instead try:

import core
import speech
core.callLater(500, lambda: speech.speakMessage ("Hello everyone !", priority = speech.priorities.Spri.NOW))

Would there not be a possibility to prevent the interruption of a message defined as priority?

No, this stops prevents the user from feeling in control. It degrades the user experience. The screen reader needs to react to the users last action.

Do you have a use case where this important?

feerrenrut avatar Nov 15 '21 02:11 feerrenrut

Thanks @feerenrut,

Do you have a use case where this important?

Yes, when speak command keys are enabled and keystrokes like "NVDA + F1" are used, for example...

The name of the command key is not fully spoken.

abdel792 avatar Nov 18 '21 18:11 abdel792

I am not personally impacted by this issue because I do not work with command key reporting enabled.

However, to progress in the analysis of this issue, I think that an import question is: Is the event a direct consequence of the keypress? The following examples are such examples where the event is a consequence of the keypress:

  • NVDA+F1: focus event on log viewer opening interrupts key name reporting
  • NVDA+control+A/B/G/S/V/etc.: focus event on various settings dialog opening interrupts keyname reporting
  • Control+I/U/B in Word: UIA event interrupt the key name reporting

I think that events should interrupt keyname reporting only if the event is not linked to the last keypress.

CyrilleB79 avatar Nov 18 '21 20:11 CyrilleB79