Repository: nvaccess/nvda

Issue:
In latest next builds, trying to update next, then makes browser events die until reboot.
### Background:

There's been a bug in NVDA for years that when we load source copies of NVDA, events in browsers fail to talk to us. Somehow, I always ignored this in source, because core developers experienced it too, however, with the introduction of https://github.com/nvaccess/nvda/issues/7563 I believe this got much worse. Every time I update next, NVDA stops responding to dynamic events until I reboot. I can still nvda+f5 to refresh however.

### Hypothesis

Since the library version is changing every time our version updates, somehow, the old code is receiving events and the new code isn't. There's something I think with this, because if I change from binary to source, and back to binary under proper working conditions, the path used to be the same, and the code would work just fine. I propose introducing a try build of NVDA that beeps upon every event responded to in a vbuff. That way, I can run that version installed, reboot, install next, then try to see if I get beeps, suggesting the old code is running.

### Steps to reproduce:

Under any earlier than latest <next|master|you choose> build of NVDA

1. visit google.com.
2. type chickens into the search box.
3. now, go to the search box again, and type "horses"

    Expected: you can press 2 to find search results for horses.
    Actual: this works.
4. Now, repeat steps 1-3 again, after updating NVDA (So long as you have a binary version you are fine). Update to either latest next or master.
    Expected: You get search results for Horses.
    Actual: You get search results for Chickens, if you get search results for anything.
5. Now, press NVDA+f5.
    Note how you now have search results for horses.

### System configuration:
NVDA version: anything post https://github.com/nvaccess/nvda/issues/7563

NVDA Installed or portable: Needs to be a binary build, other than that it doesn't matter.

Does the issue still occur after restarting your PC? No

Have you tried any other versions of NVDA? I've tried source, and the several next builds.



Discussion:
I can confirm this, but closing Firefox completely is enough to fix it for me (reboot not required).

It just falls over and crashes golden cursor, see my ticket on this. A 
needed part of nvda seems to be missing from that snap.
 Brian

bglists@blueyonder.co.uk
Sent via blueyonder.
Please address personal email to:-
briang1@blueyonder.co.uk, putting 'Brian Gaff'
in the display name field.
----- Original Message ----- 
From: "dan1982code" <notifications@github.com>
To: "nvaccess/nvda" <nvda@noreply.github.com>
Cc: "Subscribed" <subscribed@noreply.github.com>
Sent: Tuesday, October 03, 2017 4:47 PM
Subject: Re: [nvaccess/nvda] In latest next builds, trying to update next, 
then makes browser events die until reboot. (#7641)


>I can confirm this, but closing Firefox completely is enough to fix it for 
>me (reboot not required).
>
>
> -- 
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly or view it on GitHub:
> https://github.com/nvaccess/nvda/issues/7641#issuecomment-333885090 


Look at my update problems in windows 7 something is wrong with Micks idea 
of replacing the  bits that are needed by renaming the old ones and copying 
new ones to run on installation or enabling of the portable that is causing 
things to  fall over when renaming fails.
 This I have traced to a temp folder in the lib and lib 64 folders mostly 
and it means things just are not reliable any more.

Also if you do an update parts of the old version now remain in the folder 
masking any issues that revolve around files that did not update as they 
still work. These  various tickets I've been raising which to my mind have 
been ignored  are at the root of the issues here and if they are not fixed 
when people start to install the finished update version all hell will break 
loose if we are not very careful.

Just my opinion. Not trying to upset anyone, its just that this has been 
replicated on two windows 7 machines with both next and master and in both 
portable and installed copies, so its not finger trouble I can assure you. 
Its being masked as people are not sure what crud is still in the main 
folders of nvda. if you recall we had similar issues when the dictionary 
files names changed about a month back.
 Brian

bglists@blueyonder.co.uk
Sent via blueyonder.
Please address personal email to:-
briang1@blueyonder.co.uk, putting 'Brian Gaff'
in the display name field.
-----  


confirmed. also see #7640. and as @dan1982code said restart of firefox solves a problem.

Resolving patch:
diff --git a/appveyor/mozillaSyms.py b/appveyor/mozillaSyms.py
--- a/appveyor/mozillaSyms.py
+++ b/appveyor/mozillaSyms.py
@@ -29,8 +29,6 @@
 	"ISimpleDOM.dll",
 	"minHook.dll",
 	"nvdaHelperRemote.dll",
-	"VBufBackend_adobeFlash.dll",
-	"VBufBackend_gecko_ia2.dll",
 ]
 DLL_FILES = [f
 	for dll in DLL_NAMES


Test patch: