A page that has at least one list with large number of items causes performance problems with Firefox and NVDA. Two examples: A) IRCCloud: 1. Log into IRCCloud, either by using Mozilla's instance https://irccloud.mozilla.com and your LDAP credentials, or if you don't have those, create an account on https://irccloud.com and use that. For this test, either is OK. 2. Connect to Mozilla's IRC servers as usual. 3. Join one channel with a moderate number of members, such as #accessibility, and one with a huge number of members, like #developers.Make sure you're in #accessibility initially. 4. As you move around the page, everything is normal with NVDA. Speed is OK. 5. Now, find the link to the #developers channel and activate it. 6. As the page reloads, notice an immediate drastic slowdown that Firefox and NVDA don't really recover from. It all still works, it is just very slow. 7. Now, find the link to go back to #accessibility and activate it. 8. Performance will almost instantaneously return to a snappy state. B) Twitter 1. Log onto https://twitter.com. 2. Turn off NVDA's virtual buffer with NVDA+SpaceBar. 3. Use J and K to browse tweets, and when you get a notification that new tweets have loaded, press period to load them. 3. Also, on occasion, expand a conversation if there is one. 4. Notice that, as the list of tweets gets larger over time, performance degrades more and more. At about a hundred tweets or so, pressing j and k and reading the new tweet can take up to severyl seconds before NVDA starts speaking. As the list grows, and sub lists for the conversations etc. are inserted, performance degrades. Reload Twitter and go back to 20 initial tweets, everything's back to fast speeds. This is not new. I've observed this for the past two years on Twitter, but just now also saw a performance degradation on IRCCloud with only a moderately full chat view, but on a channel with lots and lots of members (like over a hundred or 200). I then verified that using Mozilla #developers, which also has a lot of channel members.
Can you upload profiler report please?
(In reply to alexander :surkov from comment #1) > Can you upload profiler report please? Sorry, I cannot, since that profiler tool in dev tools isn't accessible. :(
(In reply to Marco Zehe (:MarcoZ) from comment #2) > (In reply to alexander :surkov from comment #1) > > Can you upload profiler report please? > > Sorry, I cannot, since that profiler tool in dev tools isn't accessible. :( still? do we have bugs open?
Rather than just the size of the list alone, I suspect this has more to do with a node containing many children being updated. When a node is updated, NVDA has to re-render that entire subtree; i.e. the updated node and all its descendants. This includes adding a child/text, removing a child/text or any property change (name, state, attribute, etc.). I'm not quite sure why this would happen in IRCCloud; it sounds like that list should only change when someone joins or leaves, but maybe it changes at other times too (or maybe it's something else on that page). I'd suggest monitoring events with AccProbe and seeing what's actually happening. I do wonder whether there might be some extraneous events. In theory, it should be possible for us to do better than this; e.g. only render the text/child that got added/removed or only handle the property that got changed. There are many problems with this, though: * NVDA buffers defer events for up to 100 ms to avoid unnecessary rendering, so we'd have to queue these updates and continually adjust the queue to reflect future changes. * The rendering of a parent can be affected by its children or properties (think links with graphics or aria-label) and it'd be very difficult to calculate what should occur for these updates. This is one of many reasons I really want to get rid of buffers altogether, but that has its own set of major challenges, not least Mozilla's various text bugs. :(
Alex, can we move this bug forward somehow? Can you take over the investigation with that profiler add-on? You have the steps from comment #0. Without sighted assistance, I won't be any help in profiling this I'm afraid.
(In reply to Marco Zehe (:MarcoZ) from comment #5) > Alex, can we move this bug forward somehow? Can you take over the > investigation with that profiler add-on? You have the steps from comment #0. > Without sighted assistance, I won't be any help in profiling this I'm afraid. I think I can do profiling, but it feels slow as a hell even without accessibility.
(In reply to alexander :surkov from comment #6) > I think I can do profiling, but it feels slow as a hell even without > accessibility. Now that is concerning! I really thought this was an accessibility-related thing. So profiling might be even more interesting, but in the end not our bug. :-)
Note that for clarity, I created bug 1256707 for the Twitter issue, with extensive steps to reproduce and more information about that specific use case.
Make that bug 1256706.
Marco, is the IRCCloud case better for you with NVDA's recent vbuf speed-ups (NVDA PR #8678)? (See my suspicion in comment 4.) If so, I think we can close this.
Oh yes, it is much better! :) Closing WONTFIX.
Status: NEW → RESOLVED
Closed: 9 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.