NVDA takes the active profile as the default profile when Plugins are reloaded.

[nvaccessAuto]

Reported by Javichi on 2015-09-21 10:12
I have a profile with a trigger. When it is active and I reload appModules and globalPlugins (with NVDA + Control + F3), profile seems to remain locked. While the application that triggered the profile is running, the profile list indicates that this is triggered, although the application is not in focus. When I close the application, in the profiles list no longer it appears as triggered, but the settings are still active. It seems as if NVDA thinks the profile was the default setting.
Perhaps this error is related to ticket # 3622

[nvaccessAuto]

Comment 1 by jteh on 2015-09-21 21:31
Hmm. This is because the profile trigger is stored on the app module, but when it gets reloaded, that gets lost. It's similar to #2892.

I'm leaning towards dropping this Reload plugins functionality. It was only introduced for developers anyway, but if it's going to continue to cause problems, I'd rather it not be there at all.

[nvaccessAuto]

Comment 2 by briang1 on 2015-09-22 11:26
Yes, often its better to restart nvda in any case to clean out any junk that might be a problem.
As add ons and their local variables presumably are not stored together in some way, it would mean a complete rewrite of some code to get this to work in any case I assume.

I've never used reload plug ins indeed restart with plug ins dsabled is of more use at times.

[nvaccessAuto]

Comment 3 by Javichi on 2015-09-22 22:59
I know almost nothing NVDA code but I think that a possible solution would be to disable all profiles (triggered and manhuales, leaving only default settings) before to reload plugins.

[jcsteh]

I've taken a stab at fixing this in 0460156. It almost works, but there's one remaining problem I haven't found a solution for yet. CC @LeonarddeR.

[LeonarddeR]

Wouldn't it be possible to regenerate all nvda objects from scratch?

[jcsteh]

No. There's no registry of instantiated NVDAObjects. Furthermore, we have no idea what might be holding a reference to one of the (now broken) NVDAObjects.