Elements list freezes on huge pages or with slower browse mode implementations

[LeonarddeR]

Steps to reproduce:

1. Start MS Edge
2. Go to babbage.com
3. Go to the elements list with nvda+f7
4. Press alt+h to focus headings

Expected behavior:

Headings are shown instandly

Actual behavior:

NVDA freezes entirely

Suggested fix

Use watchdog.cancellableExecute for list refreshing, or something similar to this? At least, NVDA should be able to cancel a request for elements.

System configuration:

NVDA version: next-14051,e102a7e0

Windows version: Windows 10 version 1703 (build 15063.296)

Other questions:

Does the issue still occur after restarting your PC?
yes

Have you tried any other versions of NVDA?
Yes, NVDA from source with my i588 branch (#6131)

[jcsteh]

There's no way to "cancel" UIA calls. cancellableExecute runs the call in a background thread and simply abandons the thread if it takes too long (since you can't safely kill a thread). Aside from leaving pointless stuff running consuming resources, the Edge process would still be busy handling requests from the background thread, so it wouldn't serve any purpose. Setting timeouts for UIA calls (#6533) might help with this.

One question is whether it's a single UIA call that is taking a long time or whether it's multiple calls. The latter is more likely. If so, UIA timeouts alone won't help; we'd need to explicitly check the watchdog after each request, which is going to be rather ugly. I wonder if we can do something with a profile or trace function to avoid the need to manually check this.

[bhavyashah]

Is this ticket specific to Edge, or can its scope be expanded to include other web browsers (particularly Firefox)? On babbage.com, since there are a fairly low number of headings, pressing Alt+H took only about 3-5 seconds using Firefox 54.0.1 and NVDA 2017.2, which is a relatively minor lag. However, when on a lengthy article in Wikipedia, Alt+H, Alt+K and Alt+D results in major freezes. Has this issue already been covered by an existing ticket, or should I file a new one?

[LeonarddeR]

@bhavyashah: I think your issue fits into the scope of this ticket (i.e. it is not Edge specific). I belief we should aim onto a method that will allow the elements list to break out of a frozen quicknav iterator. However, as @jcsteh mentioned, this will be hard for UIA as UIA calls can't be cancelled.
@jcsteh commented on 24 mei 2017 00:58 CEST:

I wonder if we can do something with a profile or trace function to avoid the need to manually check this.

Could you elaborate a bit more on this?

[jcsteh]

I haven't really put much thought into it. The problem is that even if we set UIA timeouts, they only apply to a single call, but perhaps we're actually making multiple calls and the single calls never exceed the timeout and thus don't throw an exception. We really don't want to have to manually check the watchdog after every single UIA call. A profile or trace function runs for every call, so you could set one up with a context manager or something and have it check the watchdog after each call. That might be too expensive and ugly, though.

[bhavyashah]

Alright. Please let me know if any log information, STR or other troubleshooting is required for my part. Succinctly put though, pressing Alt+H in the Elements List dialog, and even opening the Elements List in the first place by pressing NVDA+F7, while viewing a lengthy Wikipedia page in Firefox, results in a freeze of 3 seconds to almost half a minute, which does seem to reflect in log contents and which can be replicated consistently. This ticket should be triaged as a P3 (if not P2) IMHO, because this is a serious regression which affects the usage and performance of a frequently used core NVDA feature.

…

On 7/27/17, James Teh ***@***.***> wrote: I haven't really put much thought into it. The problem is that even if we set UIA timeouts, they only apply to a single call, but perhaps we're actually making multiple calls and the single calls never exceed the timeout and thus don't throw an exception. We really don't want to have to manually check the watchdog after every single UIA call. A profile or trace function runs for every call, so you could set one up with a context manager or something and have it check the watchdog after each call. That might be too expensive and ugly, though. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #7197 (comment)

-- Best Regards Bhavya Shah Blogger at Hiking Across Horizons: https://bhavyashah125.wordpress.com/ Contacting Me E-mail Address: bhavya.shah125@gmail.com Follow me on Twitter @BhavyaShah125 or www.twitter.com/BhavyaShah125 Mobile Number: +91 7506221750

[LeonarddeR]

I agree that we shouldn't check the watchdog for every single call, but how about ten calls, for example? Or, even better, allow setting an interval?

[jcsteh]

Wait. I've never heard any mention of this being a regression before now. I assumed this was just reported as always being the case. When are you saying this regressed? Note that I don't consider a delay of 3 seconds to be a freeze. Realistically, if it's a big page, you can't expect this to be instant. That's the nature of gathering a list: the longer the list, the longer it takes to gather. What we don't want is a freeze greater than, say, 10 seconds without any ability to cancel. Also note that it's possible the only solution here is to just abort trying to generate the list altogether if it exceeds a certain time. @LeonarddeR, I mean that right now, if you wanted to check the watchdog for UIA calls that don't time out, you have to manually check the watchdog in your code. There's no automatic way to do this without explicit code calls. So, it's not a question of how many calls we wait before checking; it's a question of how to automate that check at all. That's why I suggested exploring a profile or trace function.

[bhavyashah]

Apologies. Regression was just factually inaccurate word choice, because indeed, this has always been the case. 3 seconds is quite understandable, but as you said, 10 seconds or more, which is the duration of freezes I can successfully replicate on longer webpages, is problematic. Hope that clears any confusion I may have inadvertently created earlier.

…

On 7/27/17, James Teh ***@***.***> wrote: Wait. I've never heard any mention of this being a regression before now. I assumed this was just reported as always being the case. When are you saying this regressed? Note that I don't consider a delay of 3 seconds to be a freeze. Realistically, if it's a big page, you can't expect this to be instant. That's the nature of gathering a list: the longer the list, the longer it takes to gather. What we don't want is a freeze greater than, say, 10 seconds without any ability to cancel. Also note that it's possible the only solution here is to just abort trying to generate the list altogether if it exceeds a certain time. @LeonarddeR, I mean that right now, if you wanted to check the watchdog for UIA calls that don't time out, you have to manually check the watchdog in your code. There's no automatic way to do this without explicit code calls. So, it's not a question of how many calls we wait before checking; it's a question of how to automate that check at all. That's why I suggested exploring a profile or trace function. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #7197 (comment)

-- Best Regards Bhavya Shah Blogger at Hiking Across Horizons: https://bhavyashah125.wordpress.com/ Contacting Me E-mail Address: bhavya.shah125@gmail.com Follow me on Twitter @BhavyaShah125 or www.twitter.com/BhavyaShah125 Mobile Number: +91 7506221750

[bhavyashah]

@LeonarddeR Do you have any thoughts on @jcsteh's #7197 (comment)? Considering this ticket has P2, we might want to try to - (1) revive technical discussion about solving this issue or (2) ascertain that the implementation cost is too significant and consequently deprioritize this ticket. Just saying...

[Adriani90]

This is not occuring in Edge Chromium 81. Closing as works for me since Edge Chromium will be distributed to most users via Windows 10 20 H1 update.

[gregjozk]

Hello,

@Adriani90 and others, I think, that unresolved issues/tickets have been closing too agressively. Certainly, this issue has not been solved yet. here are some browsers like firefox and many on chromeum platform and also IE. compare a huge webpage on all that browsers and try to change, which element would be listed in elements list. when changing it there is still a big delay.
it is just my opinion about closing issues.

[Adriani90]

Please give more details on which browsers and circumstance this occurs. If people give updates, there is no reason not to reopen in case this is still reproducible. Von meinem iPhone gesendet

…

Am 26.05.2020 um 04:02 schrieb gregjozk ***@***.***>:  Hello, @Adriani90 and others, I think, that unresolved issues/tickets have been closing too agressively. Certainly, this issue has not been solved yet. here are some browsers like firefox and many on chromeum platform and also IE. compare a huge webpage on all that browsers and try to change, which element would be listed in elements list. when changing it there is still a big delay. it is just my opinion about closing issues. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[gregjozk]

Hello,

try some books on wikibooks.org e.g. books about python or about latex, especially print versions. there you would see, why I thought, that this issue was closed too fast.
Oh, I use last published alpha of NVDA and FF 76.0.1.
Again, delay of 5 to 10 seconds is understandable, but when delay is huge, user wants to cancel operation and manually skip to chosen heading/link etc.
excuse me, if issue does not cover this example.
if it is acceptable, one more example from word or other office products, where browse mode is also possible. there are possibilities like editor's revisions, spelling errors etc.

best regards

[Adriani90]

Ups sorry yes this seems not browser specific. I am reopening.

[bhavyashah]

I do not presently have the technical knowhow to comment on the feasibility or implementation of this suggestion. However, I was wondering if it might be wiser to gradually populate the Elements List dialog when it is first opened, when a different element type is selected, or when a search string is entered in the Filter by dialog. This would be similar to how Start Menu and File Explorer searches work, wherein preliminary results show up almost instantly and the next few seconds are spent on completing the search. My understanding is that currently, NVDA goes quiet and forces the user to wait until the entire list has been populated, making those few seconds of lag prominently felt. This may reduce the load on NVDA at any single point in time thereby reducing the likelihood of freezes, give the user something to get started with, and make the experience smoother overall and in sync with the way searches work elsewhere in Windows. In large documents with hundreds of instances of a certain element type, the Elements List dialog is quite laggy making it very inefficient to use. Personally, I would be very grateful if the performance of the Elements List dialog were a subject that received more attention.

[Adriani90]

Does anyone have this issue still with the last NVDA alpha version and the newest updates of different browsers? #14888 might have also brought some benefits for this issue if I am not wrong.

[Adriani90]

I cannot reproduce this issue with NVDA 2024.1 Beta and last Firefox or Chromium browser versions. I am closing as works for me also because we don't have any updates from other users since almost 3 years. If this is still occuring, please comment and we can reopen.