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.

[nvaccessAuto]

Comment 22 by camlorn on 2015-09-29 23:56
I don't know if this pertains or sheds light, but I'm hooking both event_becomeNavigatorObject and event_gainFocus, and I'm still getting lag in Firefox that feels about like what I'd expect with the delay settings introduced in this ticket. I can look at building NVDA from before this ticket if you think that will help, but my understanding is that we shouldn't be delaying both.
For reference, Unspoken hooks both, passes them through the same function, and if it sees duplicates they're ignored.

[nvaccessAuto]

Comment 23 by James Teh <jamie@... on 2015-10-02 09:12
In commit e04e8e7:
Merge branch 't2039' into next

Incubates #2039.

[nvaccessAuto]

Comment 24 by jteh on 2015-10-02 09:19
I've hopefully fixed a few bugs, including the cursor jumping back to the focus when returning to the document (comment:21).

As discussed on IRC, I realised event_becomeNavigatorObject won't get fired early because it's a review position move, not a review object move. Unfortunately, there's currently no event for the former.

[nvaccessAuto]

Comment 25 by camlorn on 2015-10-03 16:29
So far, this seems to have done it on my end. I'll let you know if it suddenly stops working or something.

[nvaccessAuto]

Comment 27 by James Teh <jamie@... on 2015-10-26 10:47
In commit 78c3919:
Revert "BrowseModeDocumentTreeInterceptor: delay calls to setFocus when focusing due to the selection moving onto that control, and also ignore gainFocus events for a short time after the setFocus to stop the selection from being bounced around if javascript chooses to bounce the focus somewhere else."

The delay seems to be too long for some users. In addition, this seems to make focus bouncing worse rather than better in some cases. Reverting until we can come up with a better fix.
This reverts commits db1c573 and 2a00080.
Re #2039, #5411.

[nvaccessAuto]

Comment 28 by jteh on 2015-10-26 10:52
Changes:
Removed labels: incubating

[feerrenrut]

Setting the priority on this issue to 2. This seems like something that should be fixed to improve confidence in NVDA, and enable users to maximise their efficiency when navigating pages. Sporadic differences in behaviour can be quite off putting, particularly to new users. Bear in mind that this issue may be quite difficult to fix, and will likely need to be tested quite thoroughly to ensure regressions aren't introduced.

[seancurtis]

Is there any plans to fix this soon? A customer of ours that uses NVDA as their screen reader raised a bug with us relating to our dropdown menus and how bad the keyboard support is. We've built them with accessibility in mind, and the focus issue only occurs once they turn NVDA on :(

I've tested in Narrator and Voiceover but they work perfectly. Could you let us know if there are plans to fix this bug?

[cblouch]

Just ran into a similar reproducible situation on Firefox and Chrome on Windows 10. I have two containers, A and B, with focusable elements in them. A has display:none, B has display:block. Focus is on a DIV in B. If I hit enter on the DIV a script hides B, unhides A and moves focus to a DIV in A. NVDA is silent even though I moved focus to newly displayed content. If I tab away and come back the element is announced. My hack to fix was to wrap the hide script in a setTimeout, forcing the order of operations to show A, focus inside A and then hide B. Changing the order without the setTimeout also fails. This pattern of hiding something with focus in it, unhiding something else and moving focus there is pretty common. JAWS and VoiceOver on various browser handle this just fine without the timer hack. Maybe hiding a container with a focused element puts NVDA in an odd state where the next focus move is not announced.

Codepen with the failure example is here:
https://codepen.io/cblouch/pen/eVrXoY
Uncomment the NVDA Hack line and comment out the previous line to try with the setTimeout.

[Adriani90]

Closing as fixed by #11190.