Date: prev next · Thread: first prev next last

Hi Michael,

I am navigating using the arrow keys.
Thinking of it i am still using LibreOffice 7.1.5.
So at the moment i am not sure if this bug is still present.


Am 17.12.2021 um 16:11 schrieb Michael Weghorn:
Hi Simon,

out of interest: How are you navigating through the sheet? Are you using the arrow keys (left, right, up, down) on a keyboard? It would definitely be interesting to hear whether the issue is still present once the problem mentioned by Richard has been fixed.

Kind regards,

On 17/12/2021 15.31, Simon Eigeldinger wrote:
Hi Guys,

I also have something to that issue as well.
Though i don't know if it is the same sluggishness.
i have the feeling it has something to do with loosing focus or having tracking issues. When navigating very quickly through the sheet NVDA can't track the cursor in the sheet window and on the braille display you just see the word Cell.
Speech stops after that.
You can see that the cursor still moves because when you alt+tab out of the window and back in again you are on the cell where you wanted to be. The problem is then when navigating to the next cell you have the same tracking/focus issues again.
The problem is a pretty old one i guess.


Am 17.12.2021 um 15:05 schrieb Michael Weghorn:
Hi Richard,

I can reproduce the behavior you describe, though the lag is only about 4-5 seconds in my case.

I'd suggest to create 2 bug reports in Bugzilla to keep track of this:

* one bug report for the slowness (the first two aspects you mention)
* one bug report for the full "accessibility hierarchy of the cell" being announced

More technically: I've taken a first look at the first one. It seems that a significant amount of time is spent on retrieving/generating an accessible description of involved accessibility objects.

For the second issue: To my understanding, screen readers usually only announce the "hierarchy" of a focused object up to the point from which it's different from the previously focused object. One potential explanation for the current behavior could be that for some reason it's not exposed to NVDA that the previously selected cell is a "sibling" of the one selected afterwards, or somehow focus is on another accessibility object in between.

Both issues require a closer analysis from a development perspective, so unfortunately I currently have no idea what you could do from a user perspective to avoid this.

Both issues don't occur when just navigating through the spreadsheet using the arrow keys (i.e. without making any changes) or when using the Orca screen reader with the gtk3 VCL plugin on Linux.

Kind regards,

On 16/12/2021 18.49, Richard B. McDonald wrote:

I am using Windows 10, LibraOffice 7.2.4 and NVDA 2021.3.  with Calc, there
is a great amount of sluggishness, as outlined below:

- With a spreadsheet open, each time I enter a number into a cell, there is
like a 15 second delay before NVDA responds with the number entered.

- When using the enter or arrow keys after entering a number into a cell to
move to a new cell, it takes like 15 seconds before NVDA responds.

- Generally, after performing any of the two above actions, the full file
path and file name is spoken.

I do not have any special settings in either NVDA or LO.  When using JAWS and Excel, I experience none of this sluggishness.  What is causing this?



To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
Privacy Policy:


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.