Hi All, There was lots of movement on the Addon front in Whistler, so I think we now have a more clear picture of the architecture and next steps.
A big piece of good news is that the desktop team a while ago started working on an explicit addon API for desktop. This work has already progressed quite far and is expecting to land in Gecko 42 (though obviously there's always a risk of running into last-minute problems). To make this extra awesome, the addon API has been explicitly designed to work in a multi-process environment. Where both the addon itself, and webpages that addons affect are running in separate child processes. This is exactly what we need for FirefoxOS, so it's a very fortunate alignment. So with that in mind, here is what I think we need to do to get addons working in FirefoxOS: ** Getting basic support in place ** There's a decent amount of basic support already implemented by the desktop team. We should get this code up and running in FirefoxOS. For example, the code to enumerate the set of active tabs is likely going to be very different on desktop, Fennec and FirefoxOS, so we need to make sure that the appropriate abstractions as well as FirefoxOS backends are working. I'm sure there are lots of things like this. ** Enable addons to be installed/enumerated/uninstalled ** Clearly we need to enable the user to install addons. And since all of our UI uses (more or less) normal web content we can't rely on internal chrome APIs to enable this. Instead we should expand the current mozApps API to enable installing and enumerating addons. We can either do this by adding something like mozApps.installAddon(url), or by making mozApps.installPackage(url) also support addon packages. This way Gaia can, where needed, to enumerate all addons, read metadata about the addon, and uninstall an addon. I think it might even enable us to disable/reenable an addon without uninstalling/reinstalling it. ** Decide on a package format for addons ** I think it's really good if we can use the same packaging format for addons for Firefox desktop/fennec/iOS as for FirefoxOS. Given that all we need is to be able to zip up a bunch of web resources and a JSON manifest, and then sign that zip, it seems like getting alignment should be quite easy. Essentially we just need to agree on the name of that manifest and what exact property names to use. There were some opinions about this at the addons-for-FirefoxOS meeting in Whistler, so I propose that the people that feel strongly about this get together with the desktop and fennec addon teams and decide on a format. ** Implement more addon APIs ** We will likely need to add lots of hooks hooks to various parts of gecko and Gaia to enable addons to modify behavior. See the original email in this thread. Of importance here is that we think about ways that we can add APIs that we can ensure remain stable between FirefoxOS versions since addons that only use such APIs are guaranteed to work even when the user updates FirefoxOS. We should definitely collaborate with the desktop and fennec teams here. My goal is to enable developers to write addons where the majority of addon logic is shared between our different products, but where there is just enough product-specific logic to get things like UI to look great everywhere. ** Implement some way to make it easier for Gaia to add addon APIs ** I think lots of things that we'll want to enable addons to do will require hooks in Gaia. For example the "Adding/replacing UI pieces" and "Custom Views" sections in the initial email in this thread are good examples of this. So for example it would be great to have an addon API which enables an addon to easily add an icon to the status bar. But since the system app in Gaia renders the status bar, this will clearly require the system app to participate in the implementation of this API. It would be great if adding such an API only required minimal changes to Gecko, and ensure that most of the work can be done through Gaia changes only. Obviously we'd still have to be quite conscious about what the addon API looks like. I.e. we'd have no less strong requirements on API stability and design just because the API didn't require Gecko changes. ** So who does what ** There's actually been several teams expressing interest in working on addons at this point. Which is great because I think addons are both important and a lot of work to implement. But I suspect we need to get together the FirefoxOS people that are interested and decide who does what. / Jonas On Mon, Jun 22, 2015 at 4:21 PM, Jonas Sicking <[email protected]> wrote: > Hi All, > > We've been talking about addons for FirefoxOS for a while. I'd like to > make it more concrete what we want these addons to be able to do. > > This email is long enough that I didn't want to get inteo too many > details, but clearly there are a lot of details for flush out. Though > we should definitely not figure it all out before we start > implementing. > > *** Capabilities for Addons *** > > First off, what do we want addons to be able to do? > > One thing we should generally do is to look at the Chrome Addon APIs > and see what they enable. I *believe* they have a similar architecture > to what we need, and at this point I would imagine that their API is > fairly mature. So it seems like a good idea to use as a source of > inspiration. > > But a few other ideas below. Obviously we should not implement to > implement all of these capabilities right away. Instead we should pick > the most important/powerful ones first and then implement as time > permits. > > > ** Page scripts ** > > This one is pretty clear in part because we already have basic support landed > :) > > Basically this is greasemonkey. I.e. an addon should be able to inject > a script which is evaluated in the context of a webpage. This script > can take immediate action, as well as add listeners for whatever > callbacks it wants to (events, mutation observers, timers) in order to > do stuff later. > > We should also give these scripts access to additional APIs. Thanks to > some really cool security infrastructure in Gecko, we can expose > access to APIs to the greasemonkey script which runs in a page, > without also exposing that directly to the page. The APIs I'd like to > expose are: > > * Cross site XHR without CORS > * Cross site IndexedDB > * Cross site localStorage > > It's great if we can make these APIs use the same syntax as is used > for grasemonkey-like functionality elsewhere. I know that greasemonkey > on desktop can access cross-site XHR, so we should be able to reuse > syntax there. > > > ** Add APIs ** > > I'd like to enable addons to add APIs and expose them to web pages. > > The most basic version of this is to enable the addon to expose > postMessage based APIs. Simply enabling the addon to expose a > MessagePort object which the page can used to communicate with the > addon is enough to enable the addon to implement any functionality. > > We can further think about enabling the addon to create more > "javascripty" APIs. I.e. APIs that look like real DOM APIs with > objects and functions. Possibly this can be done by using the page > script feature above. > > One of the big use cases here is to enable partners to expose custom > functionality to their own apps and websites. Other use cases are > enabling addons which expose sensitive functionality only to certain > trusted websites, and shimming APIs that aren't yet available in > Gecko. > > > ** IO behavior ** > > Another category of addons that I'd like to implement is network > policies. This can be used to implement things like ad-blockers, > privacy policies, virus scanners, parental controls and usage of > compressing proxies. > > On desktop a combination of nsIContentPolicy and various notifications > like "http-on-modify-request" supply this functionality. I believe > Chrome has a far cleaner addon API that we should look at for > inspiration. > > I.e. I would like an addon to be able to register for getting called > any time a network connection is attempted, or a network result starts > coming back. In the callback the addon should get metadata about the > request, such as if it's for an image load, a XHR load, what URI is > being loaded, what the URI of the loading page is, etc. Based on this > information the addon should then be able to modify that request, for > example by cancelling it, by providing a different result, or by > modifying request headers, by redirecting it, etc. > > But websites no longer just read and write data to the network. We > should do similar things for reading/writing to localStorage and > IndexedDB (and in the future the Cache API). I.e. we should add the > ability for an addon to react when data is written to these APIs, and > to respond with "fake" results when data is read from these APIs. > > Use cases for this could be syncing a given website data to a server, > exporting/importing data from a website, clearing tracking information > from a website, or cheating in games :) > > > ** Device data ** > > This is similar to IO behavior. However with network requests and data > stored in localStorage/IndexedDB, the data being read and written is > quite website specific. I.e. an addon that hooks into these will have > to have quite specific knowledge about the website that's > reading/writing data, or the URL being loaded. > > For APIs like Contacts and DeviceStorage this is different. An addon > that hooks into Contacts reads and writes wouldn't need to have any > knowledge of the website doing the reading/writing, nor any knowledge > about the specific contact being read/written. > > The same is largely true for DeviceStorage where simply looking at the > file type tell you most of what you need to know. > > It would be great to enable addons to hook in to reads and writes to > Contacts and DeviceStorage. This could enable things like syncing > contacts to gmail, adding DeviceStorage backends for DropBox and > automatically removing geotags from any photos taken. > > We can also add similar hooks to DataStore. However as we're moving to > a "more webby, less appy" model, it's possible that we'll be able to > use DataStore less and IndexedDB more. So I'm not sure exactly what > the future of DataStore will be. Though this thread is the wrong place > to debate that. > > > ** Phone behavior ** > > One of the primary pieces of functionality of a smartphone is the > phone. I.e. phone calls and SMS/MMS. While these are old and boring > technologies, they are still heavily used. > > I think it would be great to add hooks to enable addons to react to > incoming and outgoing phone calls and SMS/MMS. > > Ideally this would not be done by having the addons modify the Gaia > app frontends, but rather by having the addons hook in to the > phone/SMS/MMS backends. Both because it'll be easier for addons to > hook in at that level, and because we can keep backend hooks stable > even when we update Gaia/FirefoxOS to users. > > The use cases here are things like auto-responders to SMS/MMS, > blocklisting phone numbers, preventing drunk dialing to ex > boyfriends/girlfriends and encrypting SMS/MMS messages. > > Somewhat related is enabling addons to participate in Wifi network > selection. It would be great to enable an addon to be told whenever we > do a wifi scan and tell it what networks were found to enable to > automatically join any of them. > > Using this addons can be developed for automatically joining free Wifi > networks, or joining wifi networks from a given provider. > > > ** HTML behavior ** > > There are several HTML features that would be interesting to allow > addons to hook in to. > > One thing that we're currently looking at prototyping using an addon > is a password manager. Password managers like 1password is something I > think would be great to bring to FirefoxOS. > > Similarly are form-fill addons. I.e. ones that can fill out creditcard > information or address information. Also addons which synchronize > autocomplete data with desktop browsers would be great. > > I'm not exactly sure how to expose these form-related capabilities to > addons. Possibly it can simply be done using page scripts described > above. But possibly we should add callbacks for when form fields are > added or changed on a webpage, and when they are submitted or focused > by the user. > > Another HTML feature I could see wanting to hook in to is window.open > in order to allow better popup blockers to be written. Right now our > popup blockers follow very generic rules which means that websites can > work around them. It would be great to see addons which crowdsource > lists of websites which should get a more strict treatment. > > In general it would be nice if we could allow addons to provide > blacklists for any of the features that we guard using security > policies. That includes things like window.open, geolocation, > notifications and of course all the APIs that we use signing for. > > > ** Adding/replacing UI pieces ** > > On desktop I believe it's quite popular for addons to add buttons and > other pieces of UI to the browser. > > I think it would be cool if we allowed addons to add icons and buttons > to places like the status bar, the home screen, or notification > center. The addon would then have the ability to change the contents > of the icon, as well as be notified if the user clicks the icon. > > Likewise we could enable addons to add sections to the settings app, > or augment existing sections with additional items. > > We could do this by having the addon describe the name and icon and > type (toggle, text, etc) of a given item, and for subsections provide > the HTML that should be rendered. > > I think we might also need to enable addons to *replace* some icons, > rather than just add new ones. I think some of our partners have > wanted to change behavior of some of our icons, it'd be great if they > can do that by simply pre-installing an addon. > > ** Themes ** > > I think these are pretty well understood at this point, so I don't > think I need to go into them. We may want to threat themes as addons, > or we might want to treat them as a separate thing, I'm not sure. > > Only thing I'll add is that it might be cool to at some point enable > addons to set theme variables so that you can create themes which for > example pull a new background image every day from a photo stream, or > which slowly changes the color on some text throughout the day. > > ** Custom views ** > > This is something that has been discussed for the "new gaia > architecture" and which generally sounds very cool. I suspect others > have done more thinking than me here, so I'll leave for others to fill > in. > > Only thing I would add is that I suspect that the custom views will > many times want to link to additional resources bundled with the > addon, like JS and CSS files. We should also make sure that these > views are themeable like the rest of gaia. > > > *** Addon architecture *** > > ** Installation ** > > While we should get rid of installation of "apps", Iwe still will need > to have installations of addons. It simply doesn't seem to make sense > to me to navigate to an addon which changes behavior of other websites > or of the phone. > > So I think we'll need something like a marketplace or > addons.mozilla.org where users can go and install addons. > > ** Cross-product ** > > I also think that it's great if we can make it possible for addon > authors to create addons that work across Firefox Desktop, Fennec, > Firefox for iOS and FirefoxOS. > > I'm told that it's already possible to write addons which work across > Desktop and Fennec, so seems like it would be possible for us to reuse > the same format for FirefoxOS as well. > > But packaging isn't everything. We need to make it possible to write > the scripts of the addons such that they work across our different > products. > > That does not mean that we have to make existing desktop and/or fennec > addons work out of the box on FirefoxOS. It's great if we can make > that possible, but I suspect that the different process architecture > and different UI of FirefoxOS is going to make that hard. > > What I'm instead hoping is that whatever the APIs that we implement on > FirefoxOS and expose to addons, that we also implement and expose on > other Firefox products. > > We should also consider using, when possible, APIs that other browsers > expose to addons. I think the Chrome addon APIs deal with similar > constraints as we do for FirefoxOS, so it's possible that we can reuse > APIs from there. Doing this will make it easier to port addons between > browsers. > > ** Stability guarantees ** > > We should separate addons which use "stable APIs" from ones that use > "unstable APIs". By which I mean APIs that we guarantee will work when > the user updates FirefoxOS. > > In particular, an addon which uses "page scripts" only to inject > scripts into web pages, but not into gaia pages, will be unaffected if > the user updates FirefoxOS. But if the page injects scripts into gaia > pages, then there's a risk that it'll break when the user updates > FirefoxOS. > > An addon which uses just "Phone behavior" and "Adding/replacing UI > pieces" would also be unaffected by FirefoxOS updates even if we make > changes to the dialer or the system app, as long as we ensure that the > APIs exposed towards addons is changed. > > We should definitely support both addons that use "stable APIs" and > ones that use "unstable APIs". But we need to be able to tell the two > apart. > > In part because we should tell partners that want to customize > FirefoxOS that they should use only "stable APIs". In part so that we > can tell users when they install the addon that it might be affected > when the OS is updated. And in part to simply encourage developers to > write addons which only use stable APIs. > > But above all because we likely need to develop some sort of "safe > mode" which automatically disables any unstable addons if the phone > doesn't boot properly after an OS update. Lots to be figured out here > for sure. > > ** Process model ** > > Ideally we wouldn't run the addon code in the parent process. Instead > we'd have one or more addon processes which run the addon scripts and > which we forward information to as needed. > > This will of course require that most of these APIs are asynchronous, > but that's probably a good idea anyway. It might also mean that we > need addons to declare what hooks that they want to hook into, so that > we don't spend time doing IPC unless an addon is actually going to do > something > > ** Gecko vs. Gaia ** > > I generally don't really care if we implement a given addon hook in > gecko vs. gaia. The important part is what capabilities we provide to > the addon, and what stability guarantees we provide. Other than that I > think we should do whatever is the most simple to implement. > > The only thing I would say is that we should avoid implementing addon > hooks in parts of gaia that can be replaced using custom views since > that would mean that that hook stops working when the custom view is > in effect. > > / Jonas _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
