nvaccess / nvda

NVDA, the free and open source Screen Reader for Microsoft Windows
https://www.nvaccess.org/
Other
2.09k stars 634 forks source link

Java Access Bridge not working with 2019.3 and Windows 7 #10842

Open ivnc opened 4 years ago

ivnc commented 4 years ago

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.

lukaszgo1 commented 4 years ago

I cannot reproduce this on Windows 7 x64. What version and what architecture of Java is installed exactly?

ivnc commented 4 years ago

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.

Adriani90 commented 4 years ago

cc: @michaelDCurran

ivnc commented 3 years ago

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.

ivnc commented 1 year ago

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.

Adriani90 commented 7 months ago

cc: @gerald-hartig I guess this impacts many use cases on 32bit machines, it might be worthy to look at it.

seanbudd commented 7 months ago

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

ivnc commented 7 months ago

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 commented 7 months ago

Thanks - I missed that sentence

mwhapples commented 7 months ago

@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

seanbudd commented 7 months ago

@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

seanbudd commented 7 months ago

@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

FelipeZanabria commented 5 months ago

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.