NVDA hangs mu

[dumbledad]

I wanted to take a look at Issue 523 but I'm falling before that point. If I start mu and create a simple python file, e.g.

# Write your code here :-)
#1
#2
#3
#4
#5
#6
#7
#8
#9
#10

I can navigate freely in the 'code' if NVDA is off, but when I start NVDA (or already have it running) and try to move between lines then the mu editor hangs, 'Not Responding'. This might be an NVDA issue although I can successfully navigate the file and have NVDA read each line in Visual Studio Code.

This may well be an issue with the version of windows I am on, prerelease evaluation copy build 17716.rs5_release.180711-1444

[tjguk]

Unfortunately this sounds like an interaction between a complex stack of editing software (the Qt stack we're using) and a complex visual-support stack (the NVDA software).

We obviously want to make this work, but before we start trying to build the NVDA stack from its Github repo, would you know anyone else who uses this same software and whether or not they're experiencing the same issue? In other words, can we narrow it down to any kind of environmental issue in your own setup?

Note to devs:

I assume the software is this: https://www.nvaccess.org/
and the github repo is this: https://github.com/nvaccess/nvda/

[dumbledad]

I'm not sure who else is running Canary, I'll ask around. In the meantime I'll try running the developer version and see if that sheds any light. I'll let you know if this goes away in future OS builds too.

[tjguk]

Thanks. The more useful information we can get, the better.

[dumbledad]

Running

pip install -r requirements.txt

and then

python run.py

results in a running instance of mu that does not exhibit this issue, there is no hang. The mu installed via the download still hangs though.

[ZanderBrown]

Just to check: Your running 1.0 from the windows installer and it fails but running master works?

Very weird as master hasn't seen any commits since 1.0 so would suggest something is up with the packaging

[tjguk]

Very useful info, thanks. That said, I can't see anything in the logs which suggest that anything has changed since the v1.0.0 tag. @ntoll who actually tagged and released is now away and off-line on a well-deserved holiday, so I have no easy answer.

Can you confirm, perhaps by downloading again, that you're definitely using the most recent download, please?

[tjguk]

... or as @ZanderBrown suggests, there may be an issue introduced by the packaging.

[dumbledad]

It was 64 bit, but that shouldn't matter? Shall I try downloading 32 bit second time?

[tjguk]

If it's not too inconvenient, please do. It's worth a try. At present we have nothing to go on...

[dumbledad]

Done, the 32 bit version downloaded to my machine fails too. For now I'll stick with the one run from Python

[tjguk]

Thanks for the info. This is going to be messy because, on appearances, we now have a third complex stack: the NSIS/pynsist toolkit.

If one of us gets a chance we might try to build things to see how they interact, but I don't think any of us habitually uses NVDA so there'll be a learning curve there, too.

[ntoll]

Ouch. :-(

Paging @bmustill-rose (who may have an opinion on this).

As far as I can tell it's not unusual for different screen readers to break with different bits of software in a completely inconsistent way (one screen reader works, another fails).

As for packaging... I have no idea... but it may be due to packaged Python (in Mu) being a problem. I notice that NVDA is a Python 2 project. Mu is Python 3 only and the version of Python packaged with Mu on Windows is run in a special "isolated" mode which may also (or may not) have an impact.

As a sighted developer I'm painfully aware that I have no idea what I'm doing when it comes to this sort of context -- i.e. I'm just as likely to be the problem than the assistive technology or the actual application. I'm also a Linux user too and Windows is a bit of a foreign country.

If you want to run the packaged version of Mu from the command line you should do the following in the folder into which the application is installed (e.g. c:\Program Files\Mu):

Python\python.exe Mu.launch.pyw

You'll at least be able to see any output Mu may create if there's an exception from Mu's PoV. This may (or may not) be helpful from a debugging point of view. I'd be interested if there's any output.

[bmustill-rose]

Hi

I'm not incredibly familiar with Mu's packaging procedure on Windows short of reading the provided documentation, but it would appear that parts(?) of the 1.0.0 release used QScintilla 2.10.35 which unfortunately shipped with an issue that caused the behaviour that @dumbledad is describing - E.G. launching a program that uses it whilst NVDA is running causes said program to hang. V2.10.4 resolves this particular issue.

Reading the log found at https://ci.appveyor.com/project/carlosperate/mu/build/1.0.1182 a few lines jump out at me:
475Downloading wheel: https://files.pythonhosted.org/packages/00/70/80e1986be05a82e155bd5e74cd212c0882cd222f3ff4e17a949712649982/QScintilla-2.10.3-5.10.1-cp35.cp36.cp37.cp38-none-win_amd64.whl
656Downloading wheel: https://files.pythonhosted.org/packages/39/3d/c11972517f7ba67155844c8483cc0efbd68a2f5e2a93ab5080753ce78e1d/QScintilla-2.10.3-5.10.1-cp35.cp36.cp37.cp38-none-win32.whl
However, I also noticed
58 Downloading https://files.pythonhosted.org/packages/a4/de/389d5c36290e6d62a6252a7a417681d0a3851f3e373cb63670d06c86806d/QScintilla-2.10.7-5.11.1-cp35.cp36.cp37.cp38-none-win32.whl (1.7MB)
so I don't want to say with 100% certainty that it's using the 2.10.35 version.

[bmustill-rose]

I am able to duplicate the issue when trying to package Mu from master - E.G. I am able to run through the packaging procedure to the point that I have an installer & once installed Mu runs but exhibits the issue described above. Win32.cfg / win64.cfg both reference QScintilla 2.10.3 & pynsist references these files during the packaging process so I now feel a lot more confident in saying that 1.0.0 went out using 2.10.3.

FYI, if I change either of the cfg files to use QScintilla 2.10.7, create a new installer, install and attempt to run I receive

File "Mu.launch.pyw", line 30, in <module> from mu.app import run File "pkgs\mu\app.py", line 34, in <module> from mu.interface import Window File "pkgs\mu\interface\__init__.py", line 1, in <module> from .main import Window File "pkgs\mu\interface\main.py", line 38, in <module> from mu.interface.editor import EditorPane File "pkgs\mu\interface\editor.py", line 25, in <module> from PyQt5.Qsci import QsciScintilla, QsciLexerPython, QsciAPIs ImportError: DLL load failed: The specified procedure could not be found.