LibreOffice Writer: Line numbers announced when navigating but not editing.

[Qchristensen]

In LibreOffice 5.4.2.2 and NVDA 2017.3 (also Next 14541) when Line numbers are enabled in NVDA's document formatting, they are only read aloud when navigating (eg using up and down arrows), not when typing (eg pressing enter to move to a new line).

In Braille, each line is denoted with the number symbol and line number before the text on each line when navigating, as expected. When ENTER is pressed to move to a new line. The line number itself (with no number symbol) is displayed at the start of the line. When something is typed on that line, the number symbol and line number are displayed at the start of the line.

To reproduce:

1. Ensure Line numbers are checked in NVDA's document formatting dialog.
2. Create a blank document in LibreOffice writer. If using a Braille display note that dot 1 is shown in the leftmost cell, with the flashing dots indicating this as the current cell. (In Word, there would be the number symbol, then 1, then a blank cell, then the active cell).
3. Type "a". The braille display now shows the number symbol, 1, space, then a. Only the letter typed is read aloud.
4. Press ENTER to move to a new line. The Braille shows the number 2 (letter b) with no number symbol in the first cell, which is the active cell.
5. Press up arrow. NVDA reads "a". It does not read the line number aloud. The Braille display shows the number symbol, 1, space, then a.
6. Press down arrow. NVDA reads "Line 2 blank" aloud, and indicates this correctly on the Braille display.
7. Press up arrow. NVDA reads "Line 1, a". and again indicates this correctly on the Braille display.

In Step 5 above, it seems if you press enter to move to a new line, then immediately navigate to another line without typing anything, it doesn't read the line number you move to. If we had typed a letter in between steps 4 and 5, it would have read Line 1 correctly.

Issue on LibreOffice bug tracker 78963: https://bugs.documentfoundation.org/show_bug.cgi?id=78963

[Adriani90]

@michaelweghorn Is this on the roadmap for the LO 24?

At least in NVDA, I get following errors in the log when pressing backspace to delete linefeed characters. Probably LO doesn't expose the carret offset properly when new lines are added or removed.

IO - inputCore.InputManager.executeGesture (22:32:19.000) - winInputHook (11748):
Input: kb(laptop):enter
DEBUG - editableText.EditableText._hasCaretMoved (22:32:19.016) - MainThread (26588):
Focus event. Elapsed 0.00615096 sec
IO - inputCore.InputManager.executeGesture (22:32:19.366) - winInputHook (11748):
Input: kb(laptop):backspace
DEBUGWARNING - NVDAObjects.IAccessible.IA2TextTextInfo._getCaretOffset (22:32:19.376) - MainThread (26588):
IAccessibleText::caretOffset failed
Traceback (most recent call last):
  File "NVDAObjects\IAccessible\__init__.pyc", line 244, in _getCaretOffset
_ctypes.COMError: (-2147467259, 'Unbekannter Fehler', (None, None, None, 0, None))
ERROR - scriptHandler.executeScript (22:32:19.376) - MainThread (26588):
error executing script: <bound method EditableText.script_caret_backspaceCharacter of <appModules.soffice.SymphonyDocument object at 0x08D30FF0>> with gesture 'Rücktaste'
Traceback (most recent call last):
  File "NVDAObjects\IAccessible\__init__.pyc", line 244, in _getCaretOffset
_ctypes.COMError: (-2147467259, 'Unbekannter Fehler', (None, None, None, 0, None))

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "scriptHandler.pyc", line 295, in executeScript
  File "editableText.pyc", line 288, in script_caret_backspaceCharacter
  File "appModules\soffice.pyc", line 461, in _backspaceScriptHelper
  File "documentBase.pyc", line 74, in makeTextInfo
  File "compoundDocuments.pyc", line 254, in __init__
  File "documentBase.pyc", line 74, in makeTextInfo
  File "textInfos\offsets.pyc", line 478, in __init__
  File "NVDAObjects\IAccessible\__init__.pyc", line 247, in _getCaretOffset
RuntimeError: Retrieving caret offset failed

[michaelweghorn]

@michaelweghorn Is this on the roadmap for the LO 24?

No. This will need further analysis.