Open Bug 1722298 Opened 3 years ago Updated 3 years ago

Evaluate if ContentPrincipal::AddonPolicy behavior may trigger some other unexpected side-effect by returning a stale WebExtensionPolicy instance


(WebExtensions :: General, task, P3)



(Not tracked)


(Reporter: rpl, Unassigned)



(1 file)

As part of the work on Bug 1638099, we noticed that the ContentPrincipal::AddonPolicy method does have a behavior that can change based on when the method was called for the first time, e.g. with a moz-extension principal:

  • if ContentPrincipal::AddonPolicy is called while the related WebExtensionPolicy was still disabled, then it will result in a null WebExtensionPolicy result

    • the result will be cached and so even after the WebExtensionPolicy have been enabled, any new call to ContentPrincipal::AddonPolicy for the same principal will keep returning a null WebExtensionPolicy result (while it would return the enabled WebExtensionPolicy instance if it will be called on a newly created principal instance for the same extension origin)
  • if ContentPrincipal::AddonPolicy is called while the related WebExtensionPolicy was enabled, then it will result in a pointer to the related WebExtensionPolicy instance

    • calling it again on the same principal after the WebExtensionPolicy have been disabled:
      • will still result in the same WebExtensionPolicy instance if it wasn't garbage collected yet
      • will result in a null WebExtensionPolicy instance if the disabled WebExtensionPolicy was garbage collected in the meantime

In Bug 1638099 we did hit an unexpected failure triggered by this behavior on addon reload or upgrade/downgrade due to the fact that the extension service worker registration was keeping a reference to a extension principal created before the addon was reloaded or upgraded (and so the WebExtensionPolicy was also disabled and then re-created again), but we solved the issue by making sure we unregister all the extension service workers when the extension is shutting down but the app is not.

Nonetheless we are still a bit concerned that the current behavior of ContentPrincipal::AddonPolicy could lead to some other subtle issues (e.g. if a stale
WebExtensionPolicy instance is being used for some other kind of checks, like permissions-related ones, without also checking if the instance is the active and current one) and so Shane and I agreed to file a separate low priority issue and re-evaluate this behavior separately from Bug 1638099.

Severity: -- → N/A
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.