Browse mode problems with slow/inappropriate focus changes in browsers

[nvaccessAuto]

Reported by parham on 2012-01-11 12:09
NVDA is almost always snappy when visiting most websites. However, when the website in question has a large amount of Javascript running, NVDA slows down considerably and scrolling down the page becomes hard (I.E. the focus jumps around and there's a delay between pressing an arrow key and getting a response). The responsiveness of NVDA should improve in these applications as well.
Blocked by #5411
Blocking #1544, #4719, #5032, #5359

[nvaccessAuto]

Comment 2 by jteh on 2012-01-11 21:19
Are you referring to a particular browser or both IE and Firefox?

[nvaccessAuto]

Comment 3 by parham (in reply to comment 2) on 2012-01-12 08:54
Replying to jteh:

Are you referring to a particular browser or both IE and Firefox?

Just Firefox. IE-NVDA is always a more sluggish combination than Firefox-NVDA.

[nvaccessAuto]

Comment 4 by jscuster on 2012-04-05 19:57
My apologies, I didn't see this ticket when I filed ticket 2211. Ticket 2211 deals with this bug on several sites, even ones which do not require login. We are working in harmony, The solution to one ticket will solve the other. Again, my apologies.

[nvaccessAuto]

Comment 6 by parham on 2012-04-06 04:54
Changing the title to make it refer to other websites, and not just FaceBook.
Changes:
Changed title from "NVDA Is Not Responsive When Logged In To Facebook" to "NVDA Is Not Responsive On Pages That Run A Large Amount Of Javascript"

[nvaccessAuto]

Comment 7 by jteh on 2012-04-06 06:19
I'm not convinced this responsiveness issue is caused by NVDA, and even if it is, I'm not sure we can fix it. NVDA shouldn't affect how fast focus changes, and if focus does fire slowly, this will cause the cursor to "jump" because the cursor has moved since focus was requested, making NVDA think this is a different focus event. Some other screen readers get around this by not moving focus as you move the cursor, but this causes other problems; e.g. inability to use browser commands such as the Applications key to open context menus.

Obviously, if we can come up with a good solution, we'd like to implement it. I just haven't managed to come up with one that doesn't break other things in the process.

[nvaccessAuto]

Comment 8 by parham (in reply to comment 7) on 2012-04-06 06:52
Replying to jteh:

I'm not convinced this responsiveness issue is caused by NVDA, and even if it is, I'm not sure we can fix it.

When this issue happened to me, I instantly noticed that it depended largely on the browser itself; when the CPU and memory usage went up, NVDA started lagging. This still happens.

Would it be possible, perhaps, to allow the user to disable the automatic focusing off completely, and then implement a keystroke to manually do it? This way the user can disable it when needed, sacrificing convention for speed.

Some other screen readers get around this by not moving focus as you move the cursor, but this causes other problems; e.g. inability to use browser commands such as the Applications key to open context menus.

That's true. I honestly think that NVDA's approach is much better than the approach taken by other screen readers. However, making it optional might allow NVDA to get around this when—and only when—required by the user herself.

[nvaccessAuto]

Comment 9 by jteh on 2012-05-09 20:56
Changes:
Changed title from "NVDA Is Not Responsive On Pages That Run A Large Amount Of Javascript" to "Browse mode problems with slow focus changes in browsers"

[nvaccessAuto]

Comment 10 by ateu on 2012-05-09 22:43
It also ocurrs in google chrome.

[nvaccessAuto]

Comment 11 by thiagoss2012 (in reply to comment description) on 2012-05-10 16:15
Replying to parham:

NVDA is almost always snappy when visiting most websites. However, when the website in question has a large amount of Javascript running, NVDA slows down considerably and scrolling down the page becomes hard (I.E. the focus jumps around and there's a delay between pressing an arrow key and getting a response). The responsiveness of NVDA should improve in these applications as well.

the problem also occurs mainly in google chrome. the cursor back to a live that I was, to go to a next point: I'm on page Ex a form field and go to the submit button. Done this navigation, the cursor is automatically returned to the form field.

[nvaccessAuto]

Comment 12 by jteh on 2013-05-29 21:20
Possible solution:

1. Rather than ignoring focus events based on the browse mode cursor being within the focus, do it based on time. If the user moves the browse mode cursor, ignore all focus events for a short time; e.g. 0.1 sec.
2. When moving the browse mode cursor, delay setting focus for a short time; e.g. 0.1 sec. If the cursor moves within that time, reset the timer. This will avoid pointless focus changes when the user moves the cursor fast.
   Changes:
   Milestone changed from None to near-term

[nvaccessAuto]

Comment 15 by jteh on 2015-01-14 02:46
See also #4797.
Changes:
Changed title from "Browse mode problems with slow focus changes in browsers" to "Browse mode problems with slow/inappropriate focus changes in browsers"

[nvaccessAuto]

Comment 18 by Michael Curran <mick@... on 2015-09-24 05:28
In commit 3e9d2e0:
Merge branch 't2039' into next. Incubates #2039
Changes:
Added labels: incubating

[nvaccessAuto]

Comment 19 by camlorn on 2015-09-27 15:06
it appears that we are now delaying all focus events. Would it be possible to not delay the ones caused by NVDA? Since this ticket, Unspoken has worked dreadfully in Firefox, as the only thing it can currently hook is event_gainFocus and these seem to be happening 200 MS later now. If we don't change this, is there something more appropriate that I can monitor?
I've also had more problems than usual with not clicking on what I think I've clicked on, even on web sites that this normally doesn't occur for. It feels like I'm able to sometimes get ahead of the NVDA focus, even though speech is in the right place. I know there's been a bunch of other Firefox changes, and I wasn't quite patient enough to follow this code enough to determine if this is related to this ticket; I need knowledge of other internals to make that easy, I think. I also move particularly fast as compared to most users, and this isn't easily reproduced.
For reference, I'm on next-12559,3e9d2e0.
Edit: I'm also having a lot of cases of NVDA losing my place when I leave the browser and come back.

[nvaccessAuto]

Comment 20 by jteh (in reply to comment 19) on 2015-09-28 02:35
Replying to camlorn:

it appears that we are now delaying all focus events. Would it be possible to not delay the ones caused by NVDA?

That was a very intentional change. Right now, if the user moves fast, we flood the browser with focus calls, and on a busy system/on some JS heavy sites, this causes a major perf hit.

Since this ticket, Unspoken has worked dreadfully in Firefox, as the only thing it can currently hook is event_gainFocus and these seem to be happening 200 MS later now. If we don't change this, is there something more appropriate that I can monitor?

Hmm. I actually don't know. I'll let you know if I come up with anything. I suppose you could use event_becomeNavigatorObject, assuming the user hasn't stopped the review cursor object from following focus.

I've also had more problems than usual with not clicking on what I think I've clicked on, even on web sites that this normally doesn't occur for.

I've certainly been seeing this lately too, but without this branch. I also don't see how it could be related to this branch, as we don't rely on focus for activation/clicking. I actually suspect a new Firefox bug. This is on my list of stuff to investigate while I'm with Mozilla this week.

[nvaccessAuto]

Comment 21 by camlorn on 2015-09-28 14:30
To clarify per IRC: losing my place completely is when alt-tabbing out and back into the browser, and it usually happens when moving by paragraph (i.e. not hitting focusable things). I can't reliably reproduce either, but perhaps try a nice long tvtropes page of your choosing.