Re: Sluggish browse mode keystrokes in Google Chrome


ah didn't know that one.

thanks for the tip.

On 10/22/2018 2:56 PM, Quentin Christensen wrote:
I didn't notice whether anyone had mentioned this, but since it's something not everyone knows about, for the benefit of anyone reading who wonders how GMail's (or any site's) built-in keystrokes work with NVDA's single letter navigation (eg H for heading, E for edit box, etc), the way to do it is to disable NVDA's single letter navigation.  To do this, press NVDA+SHIFT+SPACEBAR to toggle NVDA's single letter navigation.



On Tue, Oct 23, 2018 at 1:43 AM Cohn, Jonathan <jcohn@...> wrote:
I know that your example of Gmail was just an example, but I generally find that the built-in keystorkes that Gmail provides are significantly faster to navigate mail with than using the screen reader functionality.

Essentially, one can open a thread with "o" close a thread with "u", browse through the list of threads with "j" and "k" and navigate individual messages in a thread with "n" and "p".

Of course they also have keystrokes for replying, forwarding, deleting, archiving, and ignore thread.

Take care,


On 10/21/18, 5:52 PM, " on behalf of Tony Malykh" < on behalf of anton.malykh@...> wrote:

    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

    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

Quentin Christensen
Training and Support Manager

Official NVDA Training modules and expert certification now available:

Twitter: @NVAccess 

check out my song on youtube

Join to automatically receive all group messages.