Extensions were basically disabled in bug 754915 for the Web App Runtime. But.. we forgot about distribution extensions. This doesn't matter a great deal at the moment, as (I think) the Add-ons Manager would look in INSTALLDIR/webapprt/distribution/extensions - which of course should always be empty. Although it does end up doing an extra fstat in startup (only after an app update) to see if the directory exists. Still, better to play it safe and disable them. But bug 755724 got me thinking about metro and desktop apps sharing a profile, yet being under different app directories. In that case, it might make sense to look for distribution extensions in a place where the Web App runtime could potentially find them - which would not be desirable.
Since someone will probably ask what a distribution extension is... The Add-ons Manager looks in APPDIR/distribution/extensions for add-ons when the application can been updated (or on new profiles), and installs them into the profile (assuming it's not been installed this way previously and uninstalled, and assuming no newer version is already in the profile). They're typically shipped as part of the application, or put there as part of a rollout in a corporate environment.
Created attachment 636299 [details] [diff] [review] Patch v1
k9o nomination - ties to the below user story: "P1: Firefox add-ons do not get executed when running an app."
This is even more of an edge case than the profile-addons bug, not a blocker.
So how would I go about verifying this from an end-user perspective?
Put an addon's .xpi in <INSTALL-DIR>/webapprt/distribution/extensions - it needs to be named <ADDON-ID>.xpi Without the patch, launching a webapp for the first time should install that addon into the webapp's profile.
After talking with Juan actually, this sounds like this does not need verification, as since add-ons cannot be turned active due to past bugs, there's almost zero user impact here.