Improve extension conflict avoidance

[Deminder]

Extension rebasing assumes that no modifications occur during run-time. Banning run-time/optional overrides to avoid this, as suggested by @fmuellner

Would a partial disable based on `ExtensionState.DISABLING` which only reverts patches be permissible?

Thanks for the explanation. I don’t think anyone has considered that case so far (at least not that I’m aware). I don’t see how this could be addressed any other way than banning optional overrides in the review guidelines. That seems like a good idea to me to avoid potential conflicts, in particular as extensions can easily move the condition check into the override. @JustPerfection what do you think?

, would be too limiting, as pointed by @JustPerfection

Would a partial disable based on `ExtensionState.DISABLING` which only reverts patches be permissible?

How does that work with something like this? User enables the extension. Opens the settings. Toggles the Background Menu Visibility option off. backgroundMenuDisable() is getting called (runtime monkey patching). On disable, backgroundMenuEnable() is getting called. If we force extensions to apply the logic inside the monkey patched method, that will create many complications for extensions with so many settings (Just Perfection, Dash to Dock, …). The API I made for Just Perfection extension…

@jrahmatzadeh

For extensions overriding the same method or property:
IMO, conflict will be inevitable and that issue should be solved between two extensions rather than on review.

I think, further discussion about extension conflict avoidance should move here since the original post was about partially disabling.

InjectionTracker

Potentially, the way I have worked around this problem could be of help.

I wanted two of my extensions to hook into Main.panel.statusArea.quickSettings._addItemsBefore and then restore the original method during run-time.
To achieve this without conflicts during restore, I implemented an InjectionTracker which keeps track of the override history.

• The history for each overridden method/property is stored as an array of property descriptors in an dictionary Main.panel.statusArea.quickSettings.__injectionHistories.
• When overriding a method by calling injectProperty, an injection handle inj is returned which can be used to call the previous injection inj.previous.call(...) or the original method inj.original.call(...).

      const injection = this.tracker.injectProperty(
        qs,  '_addItemsBefore',
        (...args) => {
          this._setup(qs);
          injection.clear();
          injection.previous.call(qs, ...args);
        }
      );

• If all injections have been inj.clear()ed, the original method gets restored and the history dictionary removed from Main.panel.statusArea.quickSettings.__injectionHistories.

If extensions use the InjectionTracker instead of the InjectionManager, conflicts due to run-time method overrides could be mitigated.

However, conflicts due to adding and removing widgets during run-time can occur nonetheless.