1786059 - [DNR] Choose a deterministic extension prioritization order that makes sense

Status: NEW

(WebExtensions :: Request Handling, task, P3)

Description

[Rob Wu [:robwu]]

DNR rulesets should be evaluated in a sensible deterministic order, so that a user can have reasonable expectations. A reasonable choice is to prioritize the most recently installed extension, since the the user probably installs an extension to fully activate its functionality. This is not the full story - a user may simultaneously have the conflicting expectation that previously installed extensions continue to work.

Here are some of the times that could be used to determine the order:

• first install time (i.e. addon.installDate internally)
• add-on enabled (by install or after being disabled before) (no database entry for that yet, could be set in updateAddonDisabledState).
• recently updated time (i.e. addon.updateTime internally)

The advantage of relying on the first install time is that it is very predictable and immutable over the overall lifetime of an extension, across updates. It's also consistent with other internals (see below for more detail). The disadvantage is that there is no easy way for users to prioritize "old" extensions over newer extensions, short of uninstall and re-installing it (+losing extension data).

The advantage of accounting for enabled is that users could easily bump priority by disabling and re-enabling an extension (without dataloss). The disadvantage is complexity of implementation, e.g. to make sure that enable/disable was explicitly requested by the user.

I see no clear advantages to using the recently updated time - extensions could easily game this by publishing a new update, and users would have no control over the time.

---

More context over similar concepts in webRequest (=the predecessor of DNR) and within Firefox.

Currently, the order of processing results from the WebRequest API is non-deterministic. It is basically whichever extension managed to get their listener registered first (potentially via the persistent listener mechanism at startup). In practice, cancellation takes precedence over redirects (and scheme upgrades, etc.).
In contrast, Chrome's conflict resolution behavior of the webRequest API favors the "most recently installed extension". In Chrome's DNR, this is also the case ("the most recently installed extension gets priority."). In practice, it looks like their install_time is set when the extension package is installed (whether at install or on update).

Back to Firefox: we already utilize the concept of "install time" (=when the extension was first installed) for extension-managed preferences and settings, via ExtensionSettingsStore.jsm. For internal consistency, it may be preferable to also use addon.installDate in DNR.