Re: Sluggish browse mode keystrokes in Google Chrome


Tony Malykh
 

I am using gmail HTML interface, and I'm not aware of it being changed
recently. I provided gmail as an example, because this bug reproduces
with nearly 100% chance only on gmail as long as keystrokes are issued
quicly enough. I can provide you more examples, but for these other
web sites the reproducibility rate falls down to about 50%.

https://www.engadget.com/2018/10/21/facebook-may-buy-large-cybersecurity-company/
Press H K

https://www.reddit.com/
Press H H K

https://news.ycombinator.com/
Press K T

So it seems like gmail is doing something to only exacerbate this bug.
I can provide many more websites - I think I can reproduce this bug
with 50% chance on many major websites.


On 10/21/18, Brian's Mail list account via Groups.Io
<bglists=blueyonder.co.uk@groups.io> wrote:
Hmm is this the new gmail interface?
Does this affect othr sites as well.
Brian

bglists@blueyonder.co.uk
Sent via blueyonder.
Please address personal email to:-
briang1@blueyonder.co.uk, putting 'Brian Gaff'
in the display name field.
This message sent from a Windows XP machine!
----- Original Message -----
From: "Tony Malykh" <anton.malykh@gmail.com>
To: <nvda@nvda.groups.io>
Sent: Sunday, October 21, 2018 10:49 PM
Subject: [nvda] Sluggish browse mode keystrokes in Google Chrome


Hi all

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
keystroke.

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
programs running.

Best regards
Tony





Join nvda@nvda.groups.io to automatically receive all group messages.