Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NVDA freezes in Notepad++ 7.7 #9609

Closed
leonardder opened this issue May 22, 2019 · 9 comments

Comments

@leonardder
Copy link
Collaborator

commented May 22, 2019

Steps to reproduce:

  1. Install Notepad++ 7.7 X64
  2. Type a line of text.
  3. Press home to move the caret to the first character within the document

Actual behavior:

NVDA seems to freeze for around 10 seconds, then reports blank.

Expected behavior:

NVDA directly reads the first character.

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

alpha-17311

Windows version:

Windows 10 1903 build 18362.116

Name and version of other software in use when reproducing the issue:

Notepad++ 7.7 x64, either installed or portable

Other information about your system:

Also tested on another system with the same configuration. Notepad++ 7.6 works just fine.

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.

No

@DrSooom

This comment has been minimized.

Copy link

commented May 22, 2019

  1. Upgrade Scintilla from v3.56 to v4.14.

Sources: Official announcement, Changelog in the thread

I'm still on Notepad++ 7.6.6 (32-Bit). Thanks for the hint.

@leonardder: You interchanged the two behaviors. And could you please test the 32-Bit version as well?

@DrSooom

This comment has been minimized.

Copy link

commented May 22, 2019

Okay, I already opened "huc6-u+0000-u+ffff.tbi" from the HUC Braille Tables (1.94 MB, 65,568 lines) with the portable (7z) versions of Notepad++ 7.7 on Win7x64 with NVDA 2018.1. The 32-Bit version loaded the "little" tbi file (= plain/normal text file) immediately and the 64-Bit version required up to 11 seconds on an Intel Core i7 960 (more than 9 years old, but still fast enough) with 6 GB RAM. Okay, both portable Notepad++ versions were extracted on and run from a HDD, not from a SSD, on which Win7 is running. But after the tbi file was fully loaded in Notepad++ 64-Bit, searching for "266f" worked as expected. And it's the same with the navigation within this tbi file.

@Adriani90

This comment has been minimized.

Copy link
Collaborator

commented May 22, 2019

@Adriani90

This comment has been minimized.

Copy link
Collaborator

commented May 22, 2019

@leonardder I have just moved the text from expected behavior into the actual behavior and vice versa. I hope it is ok. :-)

@zahra21

This comment has been minimized.

Copy link

commented May 23, 2019

hello.
i tested with nvda 2017.2 which is the best version for me on windows xp and notepad++ 7.7 32bit.
i tested one book which is 4.19 mb in html format and even i converted it to text and cant reproduce the mentioned issue in html and text format of my book!
notepad++ opened for me these files very fast and nvda did not freeze.
but since my book is very large, (it contained 1307 when i opened it in libreoffice,) navigation in html file especially was a little slower than simple files for me.

@leonardder

This comment has been minimized.

Copy link
Collaborator Author

commented May 23, 2019

@DrSooom wrote:

... the 64-Bit version required up to 11 seconds on an Intel Core i7 960 (more than 9 years old, but still fast enough) with 6 GB RAM.

This is exactly where I"m suffering from. I updated the initial description accordingly.

@Adriani90 wrote:

I have just moved the text from expected behavior into the actual behavior and vice versa. I hope it is ok. :-)

Thanks for that!

@leonardder

This comment has been minimized.

Copy link
Collaborator Author

commented May 23, 2019

I've also found the underlying issue.

When expanding to character, NVDA sends the SCI_POSITIONAFTER message to the control, passing -1 in the case offset is 0. However, in the X64 version of Notepad++, the result of that call is the length of the document, whereas in the X86 version, it returns 0 as expected.

In the case the length of the document is returned, NVDA ends up in a while loop. This code really has to be revisited.

@zahra21

This comment has been minimized.

Copy link

commented May 24, 2019

do you mean that this bug only affected 64bit notepad++ and is not reproduceable in 32bit as i mentioned i did not observe any issue when i installed notepad++ 7.7 32bit?

@leonardder

This comment has been minimized.

Copy link
Collaborator Author

commented May 24, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.