search

biancadanforth / tracking-protection-shield-study

A Shield study to determine the optimal messaging, if any, for Tracking Protection in Firefox.
0 stars 3 forks source link

When the study ends, uninstall the addon #22

Closed biancadanforth closed 6 years ago

biancadanforth commented 6 years ago

StudyUtils.jsm should take care of this, but currently it is throwing an error when I remove the addon from about:debugging, perhaps because it's a temporarily loaded addon?:

1515815461253   addons.manager  WARN    Exception calling callback: TypeError: addon is null (jar:file:///Users/bdanforth/Projects/tracking-protection-shield-study/dist/linked-addon.xpi!/StudyUtils.jsm:787:44) JS Stack trace: uninstall/<@StudyUtils.jsm:787:44 < safeCall@AddonManager.jsm:188:5 < makeSafe/<@AddonManager.jsm:203:25 < promise callback*promiseOrCallback@AddonManager.jsm:229:3 < getAddonByID@AddonManager.jsm:3582:12 < uninstall@StudyUtils.jsm:787:5 < endStudy@StudyUtils.jsm:837:5 < async*shutdown@bootstrap.js:95:9 < callBootstrapMethod@XPIProvider.jsm:4421:20 < uninstallAddon@XPIProvider.jsm:4681:11 < uninstall@XPIProvider.jsm:5620:5 < exports.uninstallAddon@addon.js:77:19 < async*uninstall@Target.js:193:5 < invokeGuardedCallback@react-dom.js:9163:5 < executeDispatch@react-dom.js:2996:5 < executeDispatchesInOrder@react-dom.js:3019:5 < executeDispatchesAndRelease@react-dom.js:2427:5 < executeDispatchesAndReleaseTopLevel@react-dom.js:2438:10 < forEachAccumulated@react-dom.js:15626:5 < processEventQueue@react-dom.js:2638:7 < runEventQueueInBatch@react-dom.js:9230:3 < handleTopLevel@react-dom.js:9240:5 < handleTopLevelImpl@react-dom.js:9317:5 < perform@react-dom.js:14930:13 < batchedUpdates@react-dom.js:8995:14 < batchedUpdates@react-dom.js:13065:10 < dispatchEvent@react-dom.js:9392:7 < EventListener.handleEvent*listen@react-dom.js:17501:7 < trapBubbledEvent@react-dom.js:9358:12 < listenTo@react-dom.js:4182:11 < enqueuePutListener@react-dom.js:5807:3 < _updateDOMProperties@react-dom.js:6505:11 < mountComponent@react-dom.js:6160:7 < mountComponent@react-dom.js:11721:18 < performInitialMount@react-dom.js:4832:18 < mountComponent@react-dom.js:4719:16 < mountComponent@react-dom.js:11721:18 < mountChildren@react-dom.js:10612:28 < _createInitialChildren@react-dom.js:6343:27 < mountComponent@react-dom.js:6162:7 < mountComponent@react-dom.js:11721:18 < performInitialMount@react-dom.js:4832:18 < mountComponent@react-dom.js:4719:16 < mountComponent@react-dom.js:11721:18 < mountChildren@react-dom.js:10612:28 < _createInitialChildren@react-dom.js:6343:27 < mountComponent@react-dom.js:6162:7 < mountComponent@react-dom.js:11721:18 < performInitialMount@react-dom.js:4832:18 < mountComponent@react-dom.js:4719:16 < mountComponent@react-dom.js:11721:18 < performInitialMount@react-dom.js:4832:18 < mountComponent@react-dom.js:4719:16 < mountComponent@react-dom.js:11721:18 < mountComponentIntoNode@react-dom.js:9942:16 < perform@react-dom.js:14930:13 < batchedMountComponentIntoNode@react-dom.js:9964:3 < perform@react-dom.js:14930:13 < batchedUpdates@react-dom.js:8995:14 < batchedUpdates@react-dom.js:13065:10 < _renderNewRootComponent@react-dom.js:10157:5 < _renderSubtreeIntoContainer@react-dom.js:10239:21
biancadanforth commented 6 years ago

As I suspected. This is a non-issue.

Temporarily installed addons (viewable at about:debugging) are not copied into the Firefox application or user profile directory, unlike permanently installed addons (viewable at about:addons). I've run into this before, and a more detailed explanation can be found here.

This addon will be deployed as a permanent install (about:addons), which works correctly.

Therefore, while the addon successfully uninstalls when it is permanently installed via about:addons (after setting xpinstall.signatures.required to false and extensions.legacy.enabled to true in about:config), AddonManager.jsm throws an error if the addon is temporarily installed as in our test environment using Selenium WebDriver, since presumably, it only looks inside the Firefox application folder for addons and not elsewhere in the file system.

To double-check, I ran a past shield study that I know deployed successfully and uninstalled it when it was temporarily installed, and I received the same error message. I also permanently installed it and looked at the console to find the exact same ShieldUtils.jsm logs.