nvda
nvda copied to clipboard
nvaccess
Java Access Bridge not working with 2019.3 and Windows 7
Issue of a Spanish-speaking user.
Steps to reproduce:
Open Control Panel and press J to locate "Java, link, Java Control Panel". Activate it.
Actual behavior:
The focus gets lost and the object navigator is on the link. Java Control Panel is focusable but the user is unable to read anything. nvda.log this has been reported to happen on two different machines, and after reinstalling both NVDA and JRE. I and another Spanish-speaking users have been unable to reproduce this with Windows 10, although it may be a version specific issue.
Expected behavior:
NVDA reads all the content of the window, since Java Access Bridge is now bundled with the application and it enables JAB in the VM on startup.
System configuration
NVDA installed/portable/running from source:
Installed
NVDA version:
2019.3.1
Windows version:
Windows 7 (6.1.7601 service pack 1) 32 bits
Name and version of other software in use when reproducing the issue:
Other information about your system:
Other questions
Does the issue still occur after restarting your PC?
Yes
Have you tried any other versions of NVDA? If so, please report their behaviors.
Yes, JAB works as expected with NVDA 2019.2.1 in the same machine.
I cannot reproduce this on Windows 7 x64. What version and what architecture of Java is installed exactly?
The user has reproduced the issue with JRE 6, 7 and 8 on 32 bit, thus JRE architecture is the same. In case of Java 6, he has manually activated JAB
(copying the corresponding file).
Regards.
Hello.
A user has reported that this issue is also reproducible with Windows 10 32 bits. Since the original reporter also has a 32-bit system, in their case Windows 7 with SP1, this is probably a problem related only to 32-bit machines. This second report was solved by downloading JDK from AdoptOpenJDK and manually copying the file windowsaccessbridge-32.dll into system32 folder.
Regards.
Hi, according to further comments submitted to us by the reporter, the problem is that NVDA doesn't locate the file C:\Windows\system32\WindowsAccessBridge.dll and looks for C:\Windows\syswow64\WindowsAccessBridge-32.dll instead, even on a 32-bits machine.
cc: @gerald-hartig I guess this impacts many use cases on 32bit machines, it might be worthy to look at it.
Can this be reproduced on Windows 8.1, Windows 10 or Windows 11 on 32bit machines? Windows 7 is no longer supported. I am closing this for now, but can re-open if this is reproducible on 8.1/10/11
As I commented, in 2021 we had an user with a similar issue on Windows 10 32-bit, specifically Win 10 version 1909. Would you like me to ask him for more information? My original comment was:
Hello.
A user has reported that this issue is also reproducible with Windows 10 32 bits. Since the original reporter also has a 32-bit system, in their case Windows 7 with SP1, this is probably a problem related only to 32-bit machines. This second report was solved by downloading JDK from AdoptOpenJDK and manually copying the file windowsaccessbridge-32.dll into system32 folder.
Regards.
@seanbudd if a windows version no longer being supported is valid as a reason to close, can I ask what the policy would be regarding Java versions? My thought here being that as Java17 seems to be the last LTS Java release supporting 32-bit then once Java17 is no longer supported then as far as NVDA goes would this then be an issue. Unlike Windows though, (java may be more tricky to determine when it is "supported", mainly because you have builds and support from various organisations and some of those offer both free and paid for support which may also have different end dates. My concern is that this could remain as a lingering issue for ever more, or at least until there is no longer a 32-bit Windows which is supported. To see what I mean about the variety of Java support dates, see this wikipedia article https://en.wikipedia.org/wiki/Java_version_history
@mwhapples we will be forced to move to 64bit in the next few years. I think any issues with extremely ancient versions of Java we can close. I'd suggest a conservative cut off around Java SE 10/11
@mwhapples we will be forced to move to 64bit in the next few years. I think any issues with extremely ancient versions of Java we can close. I'd suggest a conservative cut off around Java SE 10/11
I am not a programmer, but looking at the JABHandler code before 2019.3, I realized that the legacy mode is missing to define the JOBJECT64 class. We also need to locate the windowsAccessBridge.dll dll, and load it in the same way as the one that is already in NVDA, depending on the architecture (x86 or x64). If the operating system is 32-bit, define: class JOBJECT64(c_int): Otherwise use c_int64 instead. I have downloaded the latest JABHandler.py from the source code, modified it to work, and also downloaded windowsAccessbridge.dll from the open jdk jre, and it worked on my system.
