On Tuesday, June 23, 2015 at 1:22:03 AM UTC+2, Jonas Sicking 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.
An add-on that is high on the wish-list in the Android community is the ability
for third-parties making Web talk with "Apps". This could for example be
performed with the
navigator.nativeConnect()
API now available for Chrome (Desktop) on:
https://github.com/cyberphone/web2native-bridge#api
Anders
> 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
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g
