Hi all @Paul, Why don't you open the ticket yourself? You have all the skills to do it. The technical description that you made of this issue is more than correct with a detailed way to reproduce the

Hi all, As Luke pointed out, this is caused by input gestures dialog trying to show more categories than category results count it has found. You can reproduce this bug across languages (which

Sorry, but I use NVDA in french language. For english language, it's the "tools" category. I don't think it's up to the user to decide whether this error is important or not. If

Hi. When an error is traced in the log, how do you as a user know that it does not impact NVDA? How can we verify that the result of the filter is correct when there is this

Gene wrote: Warnings, yes. Errors, not so much. But this one is an index off by one error. Someone coded it so that it looks up index 4 in a 4 item list that starts at 0. In other words, it has

I suspect this error has been around for a long time. Does the error only occur when you type an individual letter? It may be a bug that doesn't matter. I generally would expect people to

Hello Gene! Às 13:26 de 29/06/2022, Gene escreveu: As I said in previous message, it happens in various sections, not only mouse... But do not happen with all letters... Gene wrote: Sorry, but

Hello! A curious error... It only happens at certain categories and with certain letters... By instance, in the Mouse category, if I search by "a" don't gave errors... If

I don't know why you see the mouse category where you describe it. I have to up arrow something like seven or eight times. Once I get there, if I shift tab once to the filter field and type z,

But do the errors effect NVDA? It sounds as though the point is to provide a command to take an action. Is the action taken? I have no objection to reporting the error, but if it doesn't

Hi, I think I discovered an NVDA bug using the "input gestures" dialog. I would like you to confirm this and if so, that one of you accustomed to the ticket, make one. I

Hi, Actually, it is not NVDA that holds progress bar values - it says things according to what Firefox (or any app) tells it to say, more so if this is a live region (for live regions, provided that

This same issue exists in command prompt of course, where the process finishes almost instantly but the reading goes on for an age. I've not found any way to control either problem. I have one web

Thanks for the clarification. I do feel that the worries over security are over the top, but at the moment everyone seems to be taking this line of trying to stop people downloading stuff at their

Ah, good catch. I clearly wasn't thinking. Luke

I use Firefox, so that may be the difference. The other instance I notice this in Firefox is when downloading a file. Now that Firefox opens the downloads panel, it says downloading the filename,

This would be accurate if it was a real progress bar. I suspect it's a live region. The default percentage for speak is 10%, and it doesn't say transferring at the end. However, I couldn't reproduce

Bob Cavanaugh wrote: NVDA doesn't know what it can comfortably speak, because it doesn't know how long the progress bar is. I think one of two things could be done. 1. If we were to make progress

Hi all, I have changed my NVDA progress indicator from beep to speak, but am wondering if there is a way to refine the way progress is announced. Is there some way I can only have as many indicators

Yes, that is the major reason to change to 32-bit... Best regards, Rui Fontes NVDA portuguese team Às 21:59 de 27/06/2022, mk360 escreveu: