NVDA announce incorrect time from TMUX

[jugglinmike]

Steps to reproduce:

1. Open Windows Subsystem for Linux
2. Install tmux with the following command: sudo apt-get install tmux
3. Run tmux with the following command: tmux
4. Set the system time with the following command: sudo date -s "2021-06-29 10:59:59"
5. Press the space bar once
6. Wait for the time to advance to 11:00:00

Actual behavior:

NVDA announces "one o'clock"

Expected behavior:

NVDA announces "eleven o'clock"

System configuration

NVDA installed/portable/running from source:

NVDA installed

NVDA version:

2020.4

Windows version:

Windows 10 Home

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

• Windows Subsystem for Linux
• tmux

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.

No

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

No add-ons present

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

Yes

[josephsl]

Hi, is this the case with this particular input for tmux, or have you found a consistent pattern? Also, have you tested what Narrator says after you perform these steps? If Narrator announces “01:00”, chances are that this is specific to WSL+API in use. Thanks.

[jugglinmike]

Hi, is this the case with this particular input for tmux, or have you found a consistent pattern?

Good question; researching the answer gives a clearer picture of what's going wrong.

NVDA only seems to announce changes "on the hour," and it announces the hours from 01:00 to 10:00 accurately. As for the rest, it's a mixed bag:

• 09:00 - "nine o'clock"
• 10:00 - "ten o'clock"
• 11:00 - "one o'clock"
• 12:00 - "two o'clock"
• 13:00 - "three o'clock"
• 14:00 - "four o'clock"
• 15:00 - "five o'clock"
• 16:00 - "six o'clock"
• 17:00 - "seven o'clock"
• 18:00 - "eight o'clock"
• 19:00 - "nine o'clock"
• 20:00 - "twenty hundred hours"
• 21:00 - "one o'clock"
• 22:00 - "two o'clock"
• 23:00 - "three o'clock"

The behavior at midnight is more telling, but there's a little more to know about tmux to understand it. By default, the complete tmux status line includes a list of the open tmux "windows", the current time, and the current date, so the full string looks something like this:

[0] 0:vim 1:vim 2:bash "DESKTOP-QOPRRSQ" 00:00 29-Jun-21

When the time rolls over to a new date on midnight, then NVDA also announces the day of the month. For example:

• 00:00 29-Jun-21 - "midnight twenty-nine"
• 00:00 30-Jun-21 - "midnight thirty"

NVDA appears to be only announcing the parts of the line which have changed. Perhaps a change-detection algorithm is at fault.

Also, have you tested what Narrator says after you perform these steps? If Narrator announces “01:00”, chances are that this is specific to WSL+API in use. Thanks.

Narrator reads the complete status line, including the list of tmux windows.

It seems likely that the true conditions aren't specific to TMUX but are instead related to in-place terminal updating. Maybe I can make a simpler reproduction with a Bash script that writes terminal control characters to standard output.

[josephsl]

Hi, ah, I think this is due to live text changes in terminal. CC @codeofdusk who has worked on something like this for a while.

[codeofdusk]

This is expected behaviour, as NVDA only speaks the characters that have been inserted:

>>> nav._calculateNewText(newText="2021-06-29 11:00:00", oldText="2021-06-29 10:59:59")
['1:00:00']

Here is the latest algorithm for determining what text is actually new.

[codeofdusk]

This is not a DMP regression:

>>> diffHandler.get_difflib_algo().diff(newText="2021-06-29 11:00:00", oldText="2021-06-29 10:59:59")
['1:00:00']
>>> diffHandler.get_dmp_algo().diff(newText="2021-06-29 11:00:00", oldText="2021-06-29 10:59:59")
['1:00:00']

[feerrenrut]

@codeofdusk this seems like a good opportunity to consider expanding the diff to the word boundary (unless some upper limit of characters is reached). Have you considered this kind of approach?

[codeofdusk]

We could do this at the risk of running into #3200 again...

[Brian1Gaff]

Sounds a bit like thesize of the grabbed field is set once and then longer numbers do not fit. Maybe it needs to assume a leading 0 on single digit hours? Brian

[XLTechie]

On a totally unrelated point: are you aware of the screen program as an alternative to tmux? It has no permanent status bar.