Sluggish browse mode keystrokes in Google Chrome


Tony Malykh
 

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


Brian's Mail list account <bglists@...>
 

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


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






Travis Siegel <tsiegel@...>
 

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.

On 10/21/2018 5:49 PM, Tony 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
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



 

Hi.
I also find gmail to be slower in performance when is used in combination with chrome canary and windows 10.
On windows 7 it works fine.
I am having the latest windows 10 update 1809 and nvda 2018.3.2.
I also tried with nvda alpha portable with similar results.
It is especially slow when composing or replying emails, or when you read the body of an email.
For my kace it shouldn't be slow as I don't have conversations enabled, and I open each email in a new window using shift+enter.
I am using the new gmail interface which is not yet enabled for everyone by default as far as I know.
You can enable it in gmail's settings.
Nikos

On Mon, 22 Oct 2018 at 01:17, 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@...
Sent via blueyonder.
Please address personal email to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
This message sent from a Windows XP machine!
----- Original Message -----
From: "Tony Malykh" <anton.malykh@...>
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
>
>
>





Jonathan COHN
 

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,

Jonathan


On 10/21/18, 5:52 PM, "nvda@nvda.groups.io on behalf of Tony Malykh" <nvda@nvda.groups.io on behalf of anton.malykh@gmail.com> 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
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


Quentin Christensen
 

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.

Regards

Quentin.

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,

Jonathan


On 10/21/18, 5:52 PM, "nvda@nvda.groups.io on behalf of Tony Malykh" <nvda@nvda.groups.io 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
    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










--
Quentin Christensen
Training and Support Manager

Official NVDA Training modules and expert certification now available: http://www.nvaccess.org/shop/

Facebook: http://www.facebook.com/NVAccess 
Twitter: @NVAccess 


 

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.

Regards

Quentin.

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,

Jonathan


On 10/21/18, 5:52 PM, "nvda@nvda.groups.io on behalf of Tony Malykh" <nvda@nvda.groups.io 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
    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










--
Quentin Christensen
Training and Support Manager

Official NVDA Training modules and expert certification now available: http://www.nvaccess.org/shop/

Facebook: http://www.facebook.com/NVAccess 
Twitter: @NVAccess 

-- 
check out my song on youtube
https://youtu.be/YeWgx2LRu7Y


Sally Kiebdaj
 

Ditto. I had been turning off browse mode entirely. This is much nicer. 
Thanks! 

On Mon, Oct 22, 2018 at 5:57 PM The Wolf <hank.smith966@...> wrote:

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.

Regards

Quentin.

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,

Jonathan


On 10/21/18, 5:52 PM, "nvda@nvda.groups.io on behalf of Tony Malykh" <nvda@nvda.groups.io 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
    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










--
Quentin Christensen
Training and Support Manager

Official NVDA Training modules and expert certification now available: http://www.nvaccess.org/shop/

Facebook: http://www.facebook.com/NVAccess 
Twitter: @NVAccess 

-- 
check out my song on youtube
https://youtu.be/YeWgx2LRu7Y