Skip to content

When re-installing incompatible add-ons preserve compatibility override#15765

Merged
seanbudd merged 10 commits into
nvaccess:masterfrom
lukaszgo1:I15584
Nov 27, 2023
Merged

When re-installing incompatible add-ons preserve compatibility override#15765
seanbudd merged 10 commits into
nvaccess:masterfrom
lukaszgo1:I15584

Conversation

@lukaszgo1

@lukaszgo1 lukaszgo1 commented Nov 9, 2023

Copy link
Copy Markdown
Contributor

Link to issue number:

Fixes #15584

Summary of the issue:

When reinstalling incompatible add-on the fact that user manually overridden its compatibility was lost i.e. add-on was disabled after restart. This occurred because even though name of the add-on was added to the set of add-ons for which compatibility should be overridden, it was removed from the set after restart when uninstalling previous version of the add-on. Note that removal during uninstall is pretty much intentional i.e. when reinstalling add-on with the same name it should not be automatically marked as overridden compatibility, even if its previous version was.

Description of user facing changes

Reinstalled incompatible add-ons should no longer be forcefully disabled.

Description of development approach

Add-ons for which compatibility should be overridden on the next restart are placed in a separate state PENDING_OVERRIDE_COMPATIBILITY. They're moved to the overridden compat state after restart. The code which enables add-ons, and verifies that given bundle can be installed has been modified to take the new state into account.

Testing strategy:

  • Installed an incompatible add-on, reinstalled it and made sure it is not forcefully disabled
  • Overridden compatibility of an incompatible add-on from the Add-ons store, and verified it is enabled on the next restart
  • With listing of incompatible add-ons enabled in the store, verified that incompatible add-on can be successfully downloaded and installed
  • Manually executed test scenarios for upgrading and downgrading NVDA with incompatible add-ons from our manual testing steps

Known issues with pull request:

I have removed some (apparently dead) code from addonHandler.Addon.enable method. I'll add review comments explaining why it seems to be not needed. Please verify my assumptions when reviewing.

Code Review Checklist:

  • Documentation:
    • Change log entry
    • User Documentation
    • Developer / Technical Documentation
    • Context sensitive help for GUI changes
  • Testing:
    • Unit tests
    • System (end to end) tests
    • Manual testing
  • UX of all users considered:
    • Speech
    • Braille
    • Low Vision
    • Different web browsers
    • Localization in other languages / culture than English
  • API is compatible with existing add-ons.
  • Security precautions taken.

@lukaszgo1 lukaszgo1 requested a review from a team as a code owner November 9, 2023 13:57
@lukaszgo1 lukaszgo1 requested a review from seanbudd November 9, 2023 13:57
Comment thread source/addonHandler/__init__.py
import addonAPIVersion
raise AddonError("Add-on is not compatible and over ride was abandoned")
state[AddonStateCategory.PENDING_ENABLE].add(self.name)
if self.overrideIncompatibility:

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This code also appears not needed - enableCompatibilityOverride removes add-on from the list of blocked add-ons, so there is no reason to do so again.

@seanbudd

Copy link
Copy Markdown
Member

have you tested the various scenarios when upgrading from a non-breaking release to a breaking release?
For example, see the scenarios described here: #15439

I think much more thorough testing is required before changing this code.

@lukaszgo1

Copy link
Copy Markdown
Contributor Author

Marking as a draft until the requested testing is done. Having said that the code which handles blocked add-ons when upgrading / downgrading has not been touched in this PR, so I don't expect much troubles there.

@lukaszgo1 lukaszgo1 marked this pull request as draft November 18, 2023 17:28
@lukaszgo1

Copy link
Copy Markdown
Contributor Author

@seanbudd I have performed the test scenarios for upgrading / downgrading to different API versions from our manual testing steps, and mentioned this in the 'testing performed' section in the initial comment, so this should be ready for review. As an aside it would be really nice to create unit tests for these, as this seems quite doable, and performing these testing steps by hand is pretty tedious.

@lukaszgo1 lukaszgo1 marked this pull request as ready for review November 22, 2023 18:03

@seanbudd seanbudd left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for testing @lukaszgo1

I agree unit tests would be ideal if you'd like to add some basic ones.

Comment thread source/addonHandler/__init__.py Outdated
return _createGUIModelFromManifest(self)

@property
def _hasOverriddenCompat(self) -> bool:

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This property should probably be added to SupportsVersionCheck like similar properties

I think this property might easily get confused with overrideIncompatibility, which now is only used when compatibility should already be overriden, not pending override.

Suggested change
def _hasOverriddenCompat(self) -> bool:
def _hasOverriddenCompat(self) -> bool:
"""If True, this add-on has been manually overriden. The affects of override may be pending restart"""

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be worth adding a docstring to overrideIncompatibility as well

If True NVDA should enable this add-on where it would normally be blocked due to incompatibility

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've added docstrings you have suggested.
As to moving the property into SupportsVersionCheck, that was also my first thought when writing this PR, but now I'm not too sure about it. I placed it in the `AddonBase since:

  1. It is explicitly used only in AddonBase subclasses
  2. Adding it into AddonBase makes boundaries between addonHandler and add-on store code more clear, thoug this is probably somewhat subjective
  3. I cannot come with an use case in which it would have to be called against other subclasses of SupportsVersionCheck, and since this is private code we can always move it if the need arises

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I understand the boundaries argument, as _hasOverriddenCompat is used in addonStore.
Logically grouping it with other version related checks is more useful in my opinion.
I think long term we want to whittle down and migrate addonHandler and addonGui code to addonStore and addonStoreGui.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a huge number of properties for various add-on datastructures now.
There were 2 dev approaches to simplify them:

  • Properties based on context (bundle, installed add-on, available from add-on store)
  • Properties based on utility (version checking, status checking)

@lukaszgo1 lukaszgo1 Nov 27, 2023

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, the last two comments quite clearly explained what was the intent behind the code layout, and also what is the eventual goal for the final code layout. I have moved the property in 5a433c1, though the fact that addonStore.models.version and addonStore.models.status require lazy imports to cooperate suggests to me that there is a room for improvements in the code here, though this is certainly out of scope for this PR.

Comment thread source/addonHandler/__init__.py Outdated
Comment thread source/gui/addonGui.py
Comment thread source/addonHandler/__init__.py
@lukaszgo1

Copy link
Copy Markdown
Contributor Author

I agree unit tests would be ideal if you'd like to add some basic ones.

I was thinking more about adding unit tests for various upgrading / downgrading with incompatible add-ons scenarios, as testing these is pretty time consuming, though that is something for a follow up PR IMO.

@seanbudd seanbudd marked this pull request as draft November 26, 2023 22:37
@lukaszgo1 lukaszgo1 marked this pull request as ready for review November 27, 2023 12:24
Comment thread user_docs/en/changes.t2t Outdated
- When using say all or commands which spell text, pauses between sentences or characters no longer gradually decrease over time. (#15739, @jcsteh)
- NVDA no longer sometimes freezes when speaking a large amount of text. (#15752, @jcsteh)
- More objects which contain useful text are detected, and text content is displayed in braille. (#15605)
- When reinstalling an incompatible add-on it is no longer forcefully disabled. (#15584)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you wish to credit yourself on this topic? I am asking since you have done so on other topics.

IMO, adding the GitHub's name in the change log helps recognize one's work, but is also useful to know who has worked on each topic, e.g. for other devs/contributors.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, that was an oversight on my part.

@seanbudd seanbudd added the conceptApproved Similar 'triaged' for issues, PR accepted in theory, implementation needs review. label Nov 27, 2023

@seanbudd seanbudd left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @lukaszgo1

@seanbudd seanbudd merged commit 2423b12 into nvaccess:master Nov 27, 2023
@nvaccessAuto nvaccessAuto added this to the 2024.1 milestone Nov 27, 2023
@lukaszgo1 lukaszgo1 deleted the I15584 branch November 28, 2023 10:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

conceptApproved Similar 'triaged' for issues, PR accepted in theory, implementation needs review.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

After a second installation of an incompatible add-on, this one is disabled after restarting NVDA.

4 participants