In Excel, NVDA often decides that you haven't moved, even when you have #3558

Closed
nvaccessAuto opened this Issue Oct 3, 2013 · 10 comments

1 participant

@nvaccessAuto

Reported by camlorn on 2013-10-03 01:27
Sorry for the poor summary. I couldn't think of a good one that conveyed this concisely.
In Excel 2010, when moving across an Excel spreadsheet, NVDA is periodically deciding that you haven't actually moved. It will read the cell you just left instead of the cell you arrived at and will continue to insist that you are on the cell you just left in every way. It seems to detect that you tried to move, as it does reread the cell. I haven't been able to narrow this down to a specific procedure. Sometimes, it doesn't happen. Sometimes, it's so bad that you can only effectively read every other cell. It isn't a specific spreadsheet, and it happens on both my computers. For me, this happens with 2013.2 as well as the next branch. I'm using Excel a lot for college, and this periodically renders it unusable. Restarting NVDA sometimes helps, but sometimes does nothing.
Blocking #2920, #3586

@nvaccessAuto

Comment 1 by mdcurran on 2013-10-03 03:23
I have seen this a little. But to clarify, if you move multiple times, surely you stay one cell behind where you are, you don't stay stuck on the very first cell right? E.g. you're on A1 and you press right arrow. It says A1 (should be b1). You press right arrow and it says b1 (should be c1). Or did it still say a1?
Clearly we need to wait a bit longer before grabbing the current selection again. Perhaps we can employ something similar to caret movement where we keep checking with a time out.

@nvaccessAuto

Comment 2 by camlorn on 2013-10-03 04:00
That seems to be correct. I've had that a few times, but whenever it starts I immediately fiddle with it until it stops so I don't actually see that often.

@nvaccessAuto

Comment 3 by tspivey on 2013-10-13 09:26
I'm encountering this on windows 8, Office 2010, NVDA 2013.2.
Notice how the following log skips G24 until I go back to it. I can't get this to happen reliably, but it happened quite often yesterday.

IO - inputCore.InputManager.executeGesture (01:44:54):
Input: kb(laptop):rightArrow
IO - speech.speak (01:44:54):
Speaking [('en_GB'), u'Horizontal range  H24'](LangChangeCommand)
IO - inputCore.InputManager.executeGesture (01:44:56):
Input: kb(laptop):7
IO - speech.speak (01:44:56):
Speaking [('en_GB'), u'edit'](LangChangeCommand)
IO - speech.speak (01:44:56):
Speaking [('en_GB'), u' 7\n'](LangChangeCommand)
IO - inputCore.InputManager.executeGesture (01:44:56):
Input: kb(laptop):rightArrow
IO - speech.speak (01:44:57):
Speaking [('en_GB'), u'Sheet1  table'](LangChangeCommand)
IO - speech.speak (01:44:57):
Speaking [('en_GB'), u'5  Vertical range  I24'](LangChangeCommand)
IO - inputCore.InputManager.executeGesture (01:44:58):
Input: kb(laptop):leftArrow
IO - speech.speak (01:44:58):
Speaking [('en_GB'), u'7  Horizontal range  H24'](LangChangeCommand)
IO - inputCore.InputManager.executeGesture (01:44:58):
Input: kb(laptop):leftArrow
IO - speech.speak (01:44:59):
Speaking [('en_GB'), u'7  H24'](LangChangeCommand)
IO - inputCore.InputManager.executeGesture (01:44:59):
Input: kb(laptop):leftArrow
IO - speech.speak (01:44:59):
Speaking [('en_GB'), u'\u7206\u767a\u7684\u5a01\u529b\u3092\u767a\u63ee\u3059\u308b  description  F24'](LangChangeCommand)
IO - inputCore.InputManager.executeGesture (01:45:06):
Input: kb(laptop):rightArrow
IO - speech.speak (01:45:06):
Speaking [('en_GB'), u'4888  has formula  effective attack  G24'](LangChangeCommand)
@nvaccessAuto

Comment 4 by mdcurran on 2013-10-18 06:01
Please test the following try build:
http://community.nvda-project.org/try/t3558/nvda_snapshot_try-t3558-9641,338b7bc.exe
Please test for a good while and let me know if the problem goes away.

@nvaccessAuto

Comment 5 by camlorn on 2013-10-18 15:30
I'll do so as soon as possible. I can probably instal it tonight. I'll poke Tyler as well, in case he doesn't see this. Fortunately for this ticket, , I use Excel all the time. Testing is not a problem.

@nvaccessAuto

Comment 6 by mdcurran (in reply to comment 5) on 2013-11-11 04:17
Replying to camlorn:
Any luck with testing this? does it improve things?

@nvaccessAuto

Comment 7 by camlorn on 2013-11-12 02:51
Sorry, life got busy. I've been on it for the last 2 and a half weeks and It appears to fix it. I don't use excel extremely frequently, but I do use it for my physics lab reports, and it works with no issues. Doesn't seem to break anything else. I suggest incubation; it seems fine, and needs wider testing than I can provide at this point. Unless you wish me to test it further, I'll be over on next again.

@nvaccessAuto

Comment 9 by Michael Curran <mick@... on 2013-11-12 04:34
In [04f217a]:
```CommitTicketReference repository="" revision="04f217a5df271411ef8b5afc8abc7750cc1997f9"
Merge branch 't3558' into next. Incubates #3558.

Changes:
Added labels: incubating
@nvaccessAuto

Comment 10 by Michael Curran <mick@... on 2013-11-26 05:57
In [045bccc]:
```CommitTicketReference repository="" revision="045bcccc49f23784e6312c848d222e34fe6ef80b"
Merge branch 't3558'. Fixes #3558.

Changes:
Removed labels: incubating
State: closed
@nvaccessAuto

Comment 11 by mdcurran on 2013-11-26 05:58
Changes:
Milestone changed from None to 2014.1

@nvaccessAuto nvaccessAuto added the bug label Nov 10, 2015
@nvaccessAuto nvaccessAuto added this to the 2014.1 milestone Nov 10, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment