Last Comment Bug 767965 - Web App Runtime should disable installation of distribution extensions
: Web App Runtime should disable installation of distribution extensions
Status: RESOLVED FIXED
[qa-]
:
Product: Firefox Graveyard
Classification: Graveyard
Component: Webapp Runtime (show other bugs)
: unspecified
: All All
: -- normal
: Firefox 16
Assigned To: Blair McBride [:Unfocused] (mostly unavailable, needinfo open, reviews not)
: Jason Smith [:jsmith]
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-25 06:41 PDT by Blair McBride [:Unfocused] (mostly unavailable, needinfo open, reviews not)
Modified: 2016-03-21 12:39 PDT (History)
3 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Patch v1 (1.20 KB, patch)
2012-06-25 07:06 PDT, Blair McBride [:Unfocused] (mostly unavailable, needinfo open, reviews not)
gavin.sharp: review+
Details | Diff | Review

Description Blair McBride [:Unfocused] (mostly unavailable, needinfo open, reviews not) 2012-06-25 06:41:14 PDT
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.
Comment 1 Blair McBride [:Unfocused] (mostly unavailable, needinfo open, reviews not) 2012-06-25 07:04:21 PDT
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.
Comment 2 Blair McBride [:Unfocused] (mostly unavailable, needinfo open, reviews not) 2012-06-25 07:06:38 PDT
Created attachment 636299 [details] [diff] [review]
Patch v1
Comment 3 Jason Smith [:jsmith] 2012-06-25 18:50:14 PDT
k9o nomination - ties to the below user story:

"P1: Firefox add-ons do not get executed when running an app."
Comment 4 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-06-25 19:07:05 PDT
This is even more of an edge case than the profile-addons bug, not a blocker.
Comment 5 Blair McBride [:Unfocused] (mostly unavailable, needinfo open, reviews not) 2012-06-25 19:32:25 PDT
https://hg.mozilla.org/integration/mozilla-inbound/rev/1d8cb944f7a9
Comment 6 Ed Morley [:emorley] 2012-06-26 01:57:03 PDT
https://hg.mozilla.org/mozilla-central/rev/1d8cb944f7a9
Comment 7 Jason Smith [:jsmith] 2012-06-26 07:28:26 PDT
So how would I go about verifying this from an end-user perspective?
Comment 8 Blair McBride [:Unfocused] (mostly unavailable, needinfo open, reviews not) 2012-06-26 07:57:16 PDT
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.
Comment 9 Jason Smith [:jsmith] 2012-06-27 15:21:55 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.