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

Perform lower case comparison of add-on names when updating, and make sure not to remove the previous add-on when the current add-on fails installation #9334

Merged
merged 2 commits into from May 9, 2019

Conversation

@leonardder
Copy link
Collaborator

commented Feb 28, 2019

Link to issue number:

None

Steps to reproduce lowercase comparison issue

  1. Install an add-on called TEST
  2. Install an add-on called test

Expected

TEST and test are considered the same add-on

Actual

test is not the same as TEST, so test installs without removing TEST

Description of how this pull request fixes the issue:

When trying to find an existing add-on with the same name, use lower case string matching.

Steps to reproduce failing add-on update issue

  1. Install an add-on called test
  2. Update the add-on with a new version which onInstall function raises an exception

Expected

The old version of test remains on the system

Actual

Neither the old nor the new version of test will be available after restarting NVDA, since the old version was marked for removal.

Description of how this pull request fixes the issue:

Mark the previous add-on for removal when the new version has been installed successfully.

Testing performed:

Tested the steps to reproduce above

Known issues with pull request:

None

Change log entry:

  • Bug fixes
    • Add-ons with names that only differ in capitalization are no longer treated as separate add-ons.

@leonardder leonardder force-pushed the BabbageCom:addonNameConflicts branch from 1b5333c to 7be08a5 Mar 18, 2019

@leonardder leonardder changed the title Perform lower case comparison of add-on names when updating Perform lower case comparison of add-on names when updating, and make sure not to remove the previous add-on when the current add-on fails installation Mar 18, 2019

@feerrenrut
Copy link
Contributor

left a comment

I wonder what would be required to use a separate ID for the addons. There may be some UX concerns anyway to have multiple addons installed with the same name.

source/gui/addonGui.py Show resolved Hide resolved
@leonardder

This comment has been minimized.

Copy link
Collaborator Author

commented May 7, 2019

Yes, I think it is. It looks like everyone assumes that the name of the add-on and the folder in which it resides are equal. Regardless, NVDA only compares the name from the manifest when installing, and this logic really should be case insensitive as this pr ensures.

@feerrenrut

This comment has been minimized.

Copy link
Contributor

commented May 9, 2019

I just tested this, and to clarify; the convention is that the name of the folder matches the name of the addon, during installation of the addon nvda creates the folder to match the name of the addon. If the folder name is changed, the addon is still loaded.

@feerrenrut feerrenrut merged commit 4df274c into nvaccess:master May 9, 2019

1 check passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details

@nvaccessAuto nvaccessAuto added this to the 2019.2 milestone May 9, 2019

feerrenrut added a commit that referenced this pull request May 9, 2019

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