Firefox takes a long time/appears to freeze when loading pages with large tables

[lukaszgo1]

Edited because the web page on which I've experienced it originally is no longer available.

# Steps to reproduce:

1. Start Nightly.
2. Go to https://github.com/get-iplayer/get_iplayer
3. Move to the first table with letter t.
4. Activate link called get_iplayer.

Actual behavior:

Nothing happens not even "loading document" announcement. When you try to interact with the Firefox window you cannot, and after alt+tabbing from it and alt+tabbing back into it only web page title and frame read only is announced. To close Nightly it is required to close process from task manager. Curiously according to someone sighted Nightly window disappears from screen after alt tabbing from it.

Expected behavior:

As the resulting web page contains pretty huge table it is understandable that it needs some time to load into the virtual buffer. What would help would be to announce "loading document" to make it clear that something is loading, and make Firefox not to freeze after alt+tabbing from it during page load.

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

NVDA version alpha-16885,2ed7dbae

Windows version:

Windows 7 x64

Name and version of other software in use when reproducing the issue:

Nightly 70

Other information about your system:

Without NVDA running this isn't happening. When testing the same page in new Edge based on Chromium "Loading document" isn't announced either, but after moving focus from Edge window and back in the page is loaded and can be read. I do not know if it is relevant, but I have Nightly set to ask about which profile it should use at startup, my profiles are on a second partition, and only other installed version of Firefox on the system is 52 ESR 32-bit.

Other questions

Does the issue still occur after restarting your PC?

Yes

Have you tried any other versions of NVDA?

No

I am experiencing it from time to time on other huge web pages and as it requires to fully kill Firefox process the currently open pages are lost.
cc @MarcoZehe and @jcsteh

[MarcoZehe]

Hi Łukasz, thank you for the report! Can you try the following to see if after that, your freezes still occur? We are currently tracking a few freeze interactions between accessibility and the new local storage generation, so it would help to know if your case is one of these.

1. Open about:config in a new tab.
2. Find the pref dom.storage.next_gen.
3. It should currently be set to true (default. Use the Toggle button to toggle it to "false".
4. Restart Nightly.
5. Repeat your steps.

Does the freeze still happen?

[lukaszgo1]

@MarcoZehe Unfortunately with this variable set to false freeze still occurs.

[Adriani90]

@lukaszgo1 how is this in Firefox 72.0.1 with NVDA 2019.3 Beta 1? I cannot see this issue now at all.

[Cleversn]

This still occurs with NVDA 2019.2.1 in Firefox 72.0.1. After visiting that link, keyboard interaction becomes impossible, and objects don't respond to any click as well using NVDA's object navigator.

[lukaszgo1]

Still reproducible at my end. It happens not only on this particular web page but on other sites also, and I have to say is extremely annoying especially when you're doing something important on the second tab, as entire Firefox needs to be killed after this freeze. cc @jcsteh @MarcoZehe Is there any hance of prioritizing this, or at least investigating the cause? Is there any more info which I can provide?

[jcsteh]

As the resulting web page contains pretty huge table it is understandable that it needs some time to load into the virtual buffer. What would help would be to announce "loading document" to make it clear that something is loading

NVDA announces "loading document" if the initial load of a buffer (when a new page loads) takes longer than 1 second. The reason this doesn't happen in this case is that these links in GitHub don't actually load a new page. GitHub is a so-called single page app (SPA), so what actually happens is that the new content is loaded in and replaces the old content. So, to NVDA, this just looks like the page got updated (albeit a really massive update), rather than a new page being loaded.

I guess one way to solve this would be to have NVDA's buffer update code periodically check how long it's been running, and if it's been running for longer than 1 second, have NVDA report a message. That's harder than it sounds, but not impossible.

and make Firefox not to freeze after alt+tabbing from it during page load.

Buffer loads and updates happen in one big chunk, so while that is happening, the browser process can't do anything else. That's why the browser freezes. Aside from the difficulty of architecting things so that buffer updates can happen in chunks (C++ generators are still pretty experimental/raw), there are some other challenges in allowing this such as the possibility that the page might update in the middle of the buffer update. Also, continually suspending and resuming the buffer load would make the loading slower overall.

[Neurrone]

@jcsteh is there still a long-term plan to remove the dependence of creating the virtual buffer? And having to keep that in sync with the page. I remember hearing about that possibility a few years ago.

[Cleversn]

Hi, you might like the ObjPad add-on, which allows interacting with objects using the arrow keys, so you can for example get ride of the virtual buffer and interact with the web pages' objects directly...

[Adriani90]

@Cleversn this is super slow in complex web pages. I would say there is unfortunately no other navigation mode which is as fast as virtuall buffers. If we want good performance even on very complex web pages, I guess there is still no other way to acomplish it.

[Adriani90]

And virtual buffers allow for creating a virtual cusror which does not depend on the system focus, so you can use quick navigation keys. I don't know how Microsoft does it with Narator in scan mode, but I would assume it is also kind of a virtual buffer that they use.

[jcsteh]

There hasn't been any further progress concerning Firefox or Chrome without buffers. It's theoretically possible to do this with decent performance, but it's very difficult and requires things we don't have yet (e.g. new accessibility APIs). Buffers aren't the only way to do a virtual cursor with quick navigation, although they're the simplest way. Narrator does not use buffers.

[jcsteh]

I've been working on a bunch of fixes in Firefox over the last few weeks which will improve this significantly, though it's never going to be anywhere near instantaneous while we have buffers. Currently, I've managed to get the get_iplayer GitHub URL above (~10000 row table) down from well over a minute (maybe even several minutes) to ~25 seconds. That's still not great, but it's a pretty massive improvement. We're tracking this in https://bugzilla.mozilla.org/show_bug.cgi?id=1473310.

[jcsteh]

There's also one fix I've submitted for NVDA: #11205.

[jcsteh]

We're currently undertaking a major re-architecture of Firefox's multi-process accessibility support using a cache. With this enabled, the page referenced in the first comment here takes about 5 seconds to load. This is still very much under development and won't be ready for production use for several months yet, but I thought it worth providing an update here regardless.

[jcsteh]

Sorry for cross-posting, but some of these issues have different audiences and I'm reluctant to close any of them as duplicates given they're all slightly different.

I'm pleased to announce that Cache the World, our major re-architecture of the Firefox accessibility engine to significantly improve performance, is now ready for preview on Windows in Firefox Nightly. If you're interested in testing, see this blog post for details and testing instructions: https://blog.mozilla.org/accessibility/cache-the-world-opt-in-preview/

[jcsteh]

Cache the World is enabled by default in Firefox 113 release.