Tony, I have not had the specific problem you're discussing, and I use chrome and NVDA. However, I have issues where NVDA skips entire chunks of web pages if I use the inverted arrow pad to navigate the page. This doesn't happen when I use the numpad review keys, but if does happen with the stand-aloen arrow keys between the main keys and the numpad. It happens most often on sites like amazon.com when looking at ebooks I'm planning on borrowing/buying, and on facebook.com when trying to view postings folks have made that I get emails about. On amazon it's so bad, I don't use the arrow keys anymore to view the page content, because they miss huge chunks of the page. But, for the problem you are having, it does manifest itself if I try to start moving through a page like amazon using the page up/down keys before the page is done loading, but otherwise, it doesn't seem to happen with any regularity.
toggle quoted messageShow quoted text
On 10/21/2018 5:49 PM, Tony Malykh wrote:
I have been noticing lately that many browse mode shortcuts are
sluggish in Google Chrome, especially on large web pages. Let me try
to explain what I mean with an example.
Suppose I open a large email thread (say 20 replies) in gmail in
Google Chrome. If I press H and then K, my cursor is supposed to find
the next heading, and then find the next link after that heading and
stop there. However, if I press them quickly one after the other, then
the after finding that link the cursor would jump back to the previous
heading as if I had pressed Shift+H afterwards. In other words, the
cursor would frirst find the heading, then jump to the next link, and
then it would mysteriously jump back to that heading again, all within
a short time, like within a second. I mentioned H and K just an
example - it seems that this issue can be reproduced with almost any
two browse mode commands, such as F, E, G, and so on.
Has anyone been aware of this issue? Are there any known workarounds?
One obvious workaround is for me to wait after every single browse
mode keystroke, but that would make using Chrome too anoying - I would
have to wait for about a second after pressing any browse mode
Actually I could reproduce this issue on the other browsers too -
Firefox and IE, although on a much lesser scale. In both Firefox and
IE you need to press these keystroeks really quickly together (maybe
less than 0.1 seconds apart to reproduce it, which probably wouldn't
affect anyone. This bug is only bothersome in Chrome.
I'm using the latest NVDA 2018.3.2 and the latest Windows 10. I have a
modern laptop, so this is not an issue of running out of CPU or
memory. I don't have too many tabs open and I don't have other