search

nvaccess / nvda

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

App modules: if two or more add-ons use the same app module, the one loaded later will be used #9845

Open josephsl opened 5 years ago

josephsl commented 5 years ago

Hi,

This issue arose from a discussion on NVDA add-ons list:

Background:

There are two add-ons (let's say, A and B) that uses the same app module for various purposes. However, when NVDA loads app modules, B.AppModule will be used. This is because add-ons are loaded by traversing add-ons directory, and if two identically named app modules are found, the one traversed last will be loaded.

Steps to reproduce:

  1. Install Mozilla Apps Enhancements and Developer Toolkit add-ons from community add-ons website (the latter is available from development section).
  2. Try loading Developer Toolkit functionality from Firefox.

Actual behavior:

Dev Toolkit version of Firefox app module won't be used.

Expected behavior:

No errors.

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

Alpha.17871 and others

Windows version:

Windows 10 Version 1903

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

Firefox 67

Other information about your system:

None

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 - occurs on all known versions, including Python 3 staging builds

Additional context:

After discussing the issue with add-on authors, it was determined that Develop3r Toolkit will continue to rely on an app module for Firefox so things can be tested, and a need to move this into a global plugin was discussed, thus resolving it from add-on side. The discussion is ongoing in regards to what to do from here.

Thanks.

josephsl commented 5 years ago

Hi,

Relevant add-ons list thread: https://nvda-addons.groups.io/g/nvda-addons/topic/mozilla_enhancements_addon/32240615?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,32240615

Thanks.

ajborka commented 5 years ago

I am the developer for Developer toolkit addon mentioned in the original comment. The developer for Mozilla enhancements and I have tried chaining appModules.firefox together and other strange workarounds. However, all I end up with is import errors. It appears that two app modules with the same .py filename trying to import each other create a circular import that fails. There needs to be a namespacing methodology so two or more addons using the same executable (firefox in this case) don't conflict with each other. As it stands, NVDA only allows a single addon to run against an executable at a time. As Joseph mentioned, I can put Developer toolkit in a global plugin, but it introduces more complex code than required, and it defeats the purpose for the firefox addon.

LeonarddeR commented 5 years ago

May be a fix for this could be having an addons module, so you can import addons.addonName.appModules.appModuleName. I wonder whether we could do that dynamically while not enforcing every add-on to bundle an empty init.py in the root of the add-on.

Adriani90 commented 4 years ago

cc: @feerrenrut

CyrilleB79 commented 3 years ago

A new occurrence of this issue is currently discussed in this thread on the add-on mailing list.

With the end of mandatory human reviews to accept add-on releases on the add-on website and the future add-on store, we may expect more add-ons to be released. And thus also more such conflicts. Maybe 2022.1 would be an interesting target for this issue (since I guess that it should be implemented in a API-breaking release).

lukaszgo1 commented 3 years ago

This is a pretty interesting problem and while creating a mechanism allowing to import two appmodules for one program is certainly possible it can easily cause conflicts. What should happen if two of these modules assigns different scripts to the same keyboard command which one should win? What if the first (they always would need to be ordered somehow) modifies a given object so that the modifications in the second are no longer functional?

CyrilleB79 commented 3 years ago

This is a pretty interesting problem and while creating a mechanism allowing to import two appmodules for one program is certainly possible it can easily cause conflicts. What should happen if two of these modules assigns different scripts to the same keyboard command which one should win? What if the first (they always would need to be ordered somehow) modifies a given object so that the modifications in the second are no longer functional?

Yes, you are right: there may still be incompatibilities and add-on developers will need in any case to avoid this.

Note however that the behaviour you describe can already be seen in global plugins, e.g.:

feerrenrut commented 3 years ago

There isn't an obvious way to resolve this. To start with, I recommend that it is at least made obvious to the user that two add-ons are incompatible / conflict with each other.

seanbudd commented 2 years ago

I agree, it would be good to add an extension point for addons to register the default input gestures, functions/classes monkeypatched, and appmodules they use. We could create helper classes in NVDA core to make this easier.

josephsl commented 4 months ago

Hi,

2024 update: with the advent of add-on sotre, the issue of competition among app modules at add-on import time may intensify once we get more add-ons with identical app modules registered on the store.

Thanks.