Re: Sluggish browse mode keystrokes in Google Chrome


 

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




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