1473310 - [e10s a11y] German Wikipedia List of Tatort episodes (AKA large tables) causes slowness in e10S a11y

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect, P2)

Description

[Marco Zehe (:MarcoZ)]

STR:
1. With NVDA and Firefox running, go to https://de.wikipedia.org/wiki/Liste_der_Tatort-Folgen

Result: Document takes approximately 1 minute to load. It also depends a bit on whether the mouse is positioned somewhere and can trigger a tooltip after load, which can cause the buffer to immediately be rerendered again.

This particular page seems to trigger something we're not yet optimising for in the handler cache, and it makes the page very slow to load. Moreover, if you focus one of the episode titles, a popup is showing which displays the synopsis of the episode. That is appended to the end of the document, causing massive buffer rerendering. We cannot do much about the latter, but perhaps if we can do something about the former, the latter is not so bad any more. :)

This was reported to me by a user in Austria.

Comment 1

[James Teh [:Jamie]]

For me, the max time to load is about 25 seconds:
DEBUG - virtualBuffers.VirtualBuffer._loadBuffer (09:25:17.526):
Buffer load took 22.587 sec, 136241 chars
Even if not a minute, that's still unacceptable. What's more concerning, though, is that even if my mouse is at the top of the screen, every time I alt+tab out and back in, I get massive (10+ seconds) lags. And that's true even if the tab is in the background. So there must be something being mutated in that document for things other than mouse movement.

Re the load time, my suspicion is that this has at least something to do with the massive table on that page. It has over 1000 rows and 9 columns. If each of those columns has a header (which I'm pretty sure it does), that'll be nearly 10000 objects we have to marshal, most of them objects we've already marshaled before. The only way I can think of to deal with this is to somehow cache headers the first time they are retrieved until the table is released and return duplicate headers from that cache. That's risky - we never wanted to cache beyond a single object, as cache recursion is an ugly business - but I think it's the only way.

I think we should first try with a build with row/column headers disabled to see if that really does speed things up.

Comment 2

[James Teh [:Jamie]]

(In reply to James Teh [:Jamie] from comment #1)
> I think we should first try with a build with row/column headers disabled to
> see if that really does speed things up.

Marco, would you mind doing this? In accessible/win/ipc/handler/AccessibleHandler.cpp, alter the get_rowHeaderCells and get_columnHeaderCells functions so that they simply return E_NOTIMPL at the top (comment out the real code). You'll need to regsvr32 AccessibleHandler.dll as admin once built.

Comment 3

[Marco Zehe (:MarcoZ)]

That brings buffer load times down to about 11 seconds.

DEBUG - virtualBuffers.VirtualBuffer._loadBuffer (10:16:01.098):
Buffer load took 11.548 sec, 137259 chars

Comment 4

[James Teh [:Jamie]]

Another great real world page for testing, since it contains a ~10000 row table:
https://github.com/get-iplayer/get_iplayer/blob/master/get_iplayer

Comment 5

[James Teh [:Jamie]]

As well as the dependent bugs, https://github.com/nvaccess/nvda/pull/8678 significantly improves things here, as it doesn't re-render the whole document every time a pop-up appears on the page.

Comment 6

[James Teh [:Jamie]]

I just submitted https://github.com/nvaccess/nvda/pull/11205 to avoid unnecessary fetches of labelledBy for every object.

Comment 7

[James Teh [:Jamie]]

This is resolved by Cache the World, which is enabled by default in Firefox 113.