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
