Error installing NVDA 2022.2rc1


Roberto Perez
 

Hi community. I just updated my installed copy of NVDA 2022.1 with the release candidate of 20222.2. The installation went well, except for the fact that the portable copy that runs while NVDA is installing could not be terminated, therefore the newly installed copy could not start automatically. I got the following error message: “Error  dialog  usage: nvda.exe [-h] [-q] [-k] [-f LOGFILENAME]

                [-l {10,12,15,20,30,40,50,100}] [-c CONFIGPATH]

                [--lang LANGUAGE] [-m] [-s] [--disable-addons]

                [--debug-logging] [--no-logging] [--no-sr-flag]

                [--install | --install-silent | --create-portable | --create-portable-silent]

                [--portable-path PORTABLEPATH] [--launcher]

                [--enable-start-on-logon True|False] [--copy-portable-config]

                [--ease-of-access]

 

error: Couldn't terminate existing NVDA process, abandoning start:

Exception: [WinError 5] Access is denied.”.

Windows specifications: “Edition             Windows 11 Pro

Version 21H2

OS build             22000.739

Experience         Windows Feature Experience Pack 1000.22000.739.0”

Should I open a GitHub issue?

 

Thanks.

 

From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of tim
Sent: Wednesday, July 13, 2022 9:49 AM
To: nvda@nvda.groups.io
Subject: Re: [nvda] Screen Refresh

 

Now with edge I have restarted some downloads.

You have to use control + j and arrow down to the download.

Now hit application or shift + f10 and arrow down to resume if it shows. That depends on the sites coding.

 

On 7/12/2022 11:15 AM, Gene wrote:

If you lose connection with the Internet, no page that has finished downloading to the browser is lost.  When you open a web page, it is downloaded to the browser and it stays there, whether you are online or not, until you close the tab or window containing the page in the browser itself.

If you are downloading something and you lose contact with the Internet briefly or very briefly, I'm not sure if the download stops or resumes, though I think it stops.

This has nothing to do with the speed of the Internet, it depends on what happens when contact with a site or the Internet is interrupted.

Gene

On 7/12/2022 10:06 AM, Dave Grossoehme wrote:

Hi Joseph:  Don

't forget about the speed of the web here.  What's going to happen with all these actions, if the internet skips a beat, and goes out for a part of a second but not long enough for the computer to loose all the pages that are open with a multipage document open as well as other documents. 

Dave

 

On 7/10/2022 11:41 AM, Joseph Lee wrote:

[Edited Message Follows]

Hi,

Here's why:

Suppose a screen reader went great lengths to obtain content for whatever page you are browsing. Now suppose that, somehow, the screen reader forgets what it was looking at when you switch screens (windows/apps). If the screen reader switches back to the web browser you were using, it doesn't remember what the page "looked" like, so it goes great lengths again to obtain document content.

Now suppose that you are browsing multiple websites, perhaps using tabs to do so. Because the screen reader does not remember content you were looking at whenever screens (or tabs) are changed, the screen reader must figure out where it is, whatever it is looking at, and ask the web browser for browse mode content. Suppose this happens so quickly that you notice the screen reader is slow to respond, and a bug is filed about it.

The task performed by a screen reader to obtain browse mode content is, as a Mozilla engineer put it, "swallowing the document". That is, in order for NVDA to obtain information from a web document and convert it into a suitable representation, it needs to ask the web browser for raw document content. This takes time depending on how responsive the web browser is to requests from other apps (including NVDA) and the length of the document. It goes something like this:

  1. User (to web browser): I want to browse to a particular website.
  2. Browser (to user, after a pause): okay, here is the document you have requested.
  3. NVDA (to web browser): but wait, the user is blind, so I need a way to present the document in a suitable way.
  4. Web browser (to NVDA): what do you want me to do for you?
  5. NVDA (to web browser): I'm going to send a messenger (no joke), and you are supposed to send the raw document (complete with HTML and other code) to them.
  6. Web browser (depending on the browser the user is using): okay, I will wait for you (old browser)/hey, I gave you all the tools you need (accessibility API's for instance), so why are you asking me to give you raw content (new browser)?
  7. NVDA messenger (to web browser): here I am, give me the raw document content please.
  8. Web browser (to NVDA messenger, after gathering the raw document content in a suitable form): here it is.
  9. NVDA messenger (to NVDA): okay, I did what you've asked.
  10. NVDA (to NVDA messenger): well done, I will tell my user about it.
  11. NVDA (to user): Loading document...
  12. NVDA (to user, after the document is formatted): here it is (then starts reading from the top if the user says so).
  13. NVDA (to self): phew, that was a long trip. I don't want to go through this again. Wait, I have a notebook which I can use to jot down document content.

The bottlenecks are the messenger and subsequent document formatting steps.

Technical: the "messenger" in this interaction is a piece of NVDA called Remote Helper, a DLL called upon to inject itself into other processes (programs) for various tasks. An important task this DLL does is ask web browsers for raw document content, which is then passed onto NVDA so it can convert it into a browse mode representation. Newer web browsers are concerned about code injection, so they do their best to provide the web document in a documented way, and one such effort is IAccessible2. In theory, using an API to access web document should eliminate the need for document refreshing (NVDA+F5 in browse mode) whenever content changes, which is different than screen refreshing in JAWS (JAWS key+Escape).

Hope this answers a lot of questions.

Cheers,

Joseph

 


 

Hi,

Sometimes, logging out and back in resolves this, as this error can indicate that NVDA installer could not locate the new NVDA version to start for osme reason.

Cheers,

Joseph


Quentin Christensen
 

Roberto,

Just a quick note to let you know I saw your issue - did NVDA start normally once you restarted / logged out?

As Joseph suggested, it looks like one of those random glitches which sortes itself out when you log out, but if anyone else has a similar issue, or if you have any other problems after restarting, do please let me know.

Quentin.

On Thu, Jul 14, 2022 at 12:50 AM Roberto Perez <rober555x@...> wrote:

Hi community. I just updated my installed copy of NVDA 2022.1 with the release candidate of 20222.2. The installation went well, except for the fact that the portable copy that runs while NVDA is installing could not be terminated, therefore the newly installed copy could not start automatically. I got the following error message: “Error  dialog  usage: nvda.exe [-h] [-q] [-k] [-f LOGFILENAME]

                [-l {10,12,15,20,30,40,50,100}] [-c CONFIGPATH]

                [--lang LANGUAGE] [-m] [-s] [--disable-addons]

                [--debug-logging] [--no-logging] [--no-sr-flag]

                [--install | --install-silent | --create-portable | --create-portable-silent]

                [--portable-path PORTABLEPATH] [--launcher]

                [--enable-start-on-logon True|False] [--copy-portable-config]

                [--ease-of-access]

 

error: Couldn't terminate existing NVDA process, abandoning start:

Exception: [WinError 5] Access is denied.”.

Windows specifications: “Edition             Windows 11 Pro

Version 21H2

OS build             22000.739

Experience         Windows Feature Experience Pack 1000.22000.739.0”

Should I open a GitHub issue?

 

Thanks.

 

From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of tim
Sent: Wednesday, July 13, 2022 9:49 AM
To: nvda@nvda.groups.io
Subject: Re: [nvda] Screen Refresh

 

Now with edge I have restarted some downloads.

You have to use control + j and arrow down to the download.

Now hit application or shift + f10 and arrow down to resume if it shows. That depends on the sites coding.

 

On 7/12/2022 11:15 AM, Gene wrote:

If you lose connection with the Internet, no page that has finished downloading to the browser is lost.  When you open a web page, it is downloaded to the browser and it stays there, whether you are online or not, until you close the tab or window containing the page in the browser itself.

If you are downloading something and you lose contact with the Internet briefly or very briefly, I'm not sure if the download stops or resumes, though I think it stops.

This has nothing to do with the speed of the Internet, it depends on what happens when contact with a site or the Internet is interrupted.

Gene

On 7/12/2022 10:06 AM, Dave Grossoehme wrote:

Hi Joseph:  Don

't forget about the speed of the web here.  What's going to happen with all these actions, if the internet skips a beat, and goes out for a part of a second but not long enough for the computer to loose all the pages that are open with a multipage document open as well as other documents. 

Dave

 

On 7/10/2022 11:41 AM, Joseph Lee wrote:

[Edited Message Follows]

Hi,

Here's why:

Suppose a screen reader went great lengths to obtain content for whatever page you are browsing. Now suppose that, somehow, the screen reader forgets what it was looking at when you switch screens (windows/apps). If the screen reader switches back to the web browser you were using, it doesn't remember what the page "looked" like, so it goes great lengths again to obtain document content.

Now suppose that you are browsing multiple websites, perhaps using tabs to do so. Because the screen reader does not remember content you were looking at whenever screens (or tabs) are changed, the screen reader must figure out where it is, whatever it is looking at, and ask the web browser for browse mode content. Suppose this happens so quickly that you notice the screen reader is slow to respond, and a bug is filed about it.

The task performed by a screen reader to obtain browse mode content is, as a Mozilla engineer put it, "swallowing the document". That is, in order for NVDA to obtain information from a web document and convert it into a suitable representation, it needs to ask the web browser for raw document content. This takes time depending on how responsive the web browser is to requests from other apps (including NVDA) and the length of the document. It goes something like this:

  1. User (to web browser): I want to browse to a particular website.
  2. Browser (to user, after a pause): okay, here is the document you have requested.
  3. NVDA (to web browser): but wait, the user is blind, so I need a way to present the document in a suitable way.
  4. Web browser (to NVDA): what do you want me to do for you?
  5. NVDA (to web browser): I'm going to send a messenger (no joke), and you are supposed to send the raw document (complete with HTML and other code) to them.
  6. Web browser (depending on the browser the user is using): okay, I will wait for you (old browser)/hey, I gave you all the tools you need (accessibility API's for instance), so why are you asking me to give you raw content (new browser)?
  7. NVDA messenger (to web browser): here I am, give me the raw document content please.
  8. Web browser (to NVDA messenger, after gathering the raw document content in a suitable form): here it is.
  9. NVDA messenger (to NVDA): okay, I did what you've asked.
  10. NVDA (to NVDA messenger): well done, I will tell my user about it.
  11. NVDA (to user): Loading document...
  12. NVDA (to user, after the document is formatted): here it is (then starts reading from the top if the user says so).
  13. NVDA (to self): phew, that was a long trip. I don't want to go through this again. Wait, I have a notebook which I can use to jot down document content.

The bottlenecks are the messenger and subsequent document formatting steps.

Technical: the "messenger" in this interaction is a piece of NVDA called Remote Helper, a DLL called upon to inject itself into other processes (programs) for various tasks. An important task this DLL does is ask web browsers for raw document content, which is then passed onto NVDA so it can convert it into a browse mode representation. Newer web browsers are concerned about code injection, so they do their best to provide the web document in a documented way, and one such effort is IAccessible2. In theory, using an API to access web document should eliminate the need for document refreshing (NVDA+F5 in browse mode) whenever content changes, which is different than screen refreshing in JAWS (JAWS key+Escape).

Hope this answers a lot of questions.

Cheers,

Joseph

 



--
Quentin Christensen
Training and Support Manager


Sean Budd (NV Access)
 

Please do open a GitHub issue.

Even if this is a one-off issue, it would be good to track and fix if it, especially if it becomes more common.